Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8098556

Java 8 compiler ignores invalid [TypeArguments] in method reference expression

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Not an Issue
    • Icon: P4 P4
    • None
    • 8u45, 8u60, 9
    • tools
    • x86_64
    • windows_7

      FULL PRODUCT VERSION :
      java version "1.8.0_45"
      Java(TM) SE Runtime Environment (build 1.8.0_45-b14)
      Java HotSpot(TM) 64-Bit Server VM (build 25.45-b02, mixed mode)

      ADDITIONAL OS VERSION INFORMATION :
      Microsoft Windows [Version 6.1.7601]

      A DESCRIPTION OF THE PROBLEM :
      Section 15.13 of the Java 8 Language Specification describes method reference expressions, and one of the forms is:

          ClassType :: [TypeArguments] new

      It seems that code will compile and run OK when using method references of this form even if the list of [TypeArguments] supplied is arbitrary and meaningless, and completely unrelated to the specified ClassType.

      The trivial application pasted below instantiates two Strings using the above syntax. The first does not specify any [TypeArguments], and is valid. The second specifies some invalid [TypeArguments], yet no compilation error is reported.

      ADDITIONAL REGRESSION INFORMATION:
      Not applicable

      STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
      To reproduce:
      [1] Compile the simple Java application pasted below in "Source code for an executable test case".
      [2] Note that the code compiles successfully even though this line is invalid:

      Function<char[], String> test2 = String::<Class<?>, Short, Byte[], Thread>new; // Compiles OK!?




      EXPECTED VERSUS ACTUAL BEHAVIOR :
      EXPECTED -
      I expected the compiler to flag an error for the line with the invalid declaration of the variable "test2":

      Function<char[], String> test2 = String::<Class<?>, Short, Byte[], Thread>new; // Compiles OK!?

      The specified type arguments are completely meaningless for String instantiation, but the compiler appears to just ignore the type arguments rather than flag an error.

      It seems that the compiler treats that line as though it was written as follows:

      Function<char[], String> test2 = String::new; // Valid

      That is, the supplied invalid [TypeArguments] are simply ignored.
      ACTUAL -
      The source code compiles and runs OK, even though it is not valid.

      These are the actual results in the console output:

      s1 = ABC
      s2 = 123



      ERROR MESSAGES/STACK TRACES THAT OCCUR :
      Not applicable.

      REPRODUCIBILITY :
      This bug can be reproduced always.

      ---------- BEGIN SOURCE ----------
      package testclasstypereference;
      import java.util.function.Function;

      public class TestClassTypeReference {

          public static void main(String[] args) {
              new TestClassTypeReference().test();
          }

          // Test the use of method references of the form: "ClassType :: [TypeArguments] new"
          // See The Java Language Specification 15.13: Method Reference Expressions.
          void test() {
              
              char[] chars1 = {'A', 'B', 'C'};
              Function<char[], String> test1 = String::new; // Notional String(char[]) constructor.
              String s1 = test1.apply(chars1);
              System.out.println("s1 = " + s1); // Prints "ABC"

              // Now repeat the previous test, but include some arbitrary [TypeArguments] in the method reference.
              char[] chars2 = {'1', '2', '3'};
              // The following declaration compiles OK even though the four [TypeArguments] are meaningless.
              Function<char[], String> test2 = String::<Class<?>, Short, Byte[], Thread>new; // Compiles OK!?
              String s2 = test2.apply(chars2);
              System.out.println("s2 = " + s2); // Prints "123"
          }
      }
      ---------- END SOURCE ----------

      CUSTOMER SUBMITTED WORKAROUND :
      No workaround is necessary. The problem is that invalid code is compiling.

            mcimadamore Maurizio Cimadamore
            webbuggrp Webbug Group
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated:
              Resolved: