JDK-7046778 : Project Coin: problem with diamond and member inner classes
  • Type: Bug
  • Component: tools
  • Sub-Component: javac
  • Affected Version: 7
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: unknown
  • Submitted: 2011-05-20
  • Updated: 2012-02-24
  • Resolved: 2012-02-24
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 7 JDK 8
7u2Fixed 8 b01Fixed
Description
This program does not compile:


class X<T> {
    class Y<Z> {
         Y(T a, Z b) { }
    }

    public static void main(String[] args) {
        X<String>.Y<String> x1 = new X<String>().new Y<String>("",""); //ok
        X<String>.Y<String> x2 = new X<String>().new Y<>("",""); //fails
    }
}
Comments
SUGGESTED FIX A webrev of this fix is available at the following URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/d5f33267a06d
28-07-2011
EVALUATION It appears that javac doesn't handle type-variable substitution consistently when diamond oerator is used in conjunction with member classes. The problem lies in the fact that javac attributed a diamond AST node as follows: new X<String>.new Y<> has type: X<String>.Y [where Y is 'raw'] This leads to problem when the synthetic constructor is accessed as a member of X<String>.Y, as javac tries to replace formal type-vaiables (T,Z) with a set of actual arguments which is smaller (String). This lead to a bad substitution and to a spurious compiler error. In order to guarantee better interoperability with type-variable substitution, the diamond AST node should be attributed as: X<String>.Y<Z>
20-05-2011