Bug ID: JDK-7109947 Diamod operator causes an unexpected compilation error

Type: Bug
Component: tools
Sub-Component: javac
Affected Version: 7

Priority: P4
Status: Closed
Resolution: Not an Issue
OS: windows_7
CPU: x86

Submitted: 2011-11-09
Updated: 2012-03-20
Resolved: 2011-11-10

FULL PRODUCT VERSION :
java version "1.7.0_01"
Java(TM) SE Runtime Environment (build 1.7.0_01-b08)
Java HotSpot(TM) 64-Bit Server VM (build 21.1-b02, mixed mode)

ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows [Version 6.1.7601]

A DESCRIPTION OF THE PROBLEM :
Let's take class javax.xml.ws.Holder<T> for example.

This code compiles without error:
Holder<Object> holder = new Holder<Object>("abc");

If we turn to use the diamond operator:
Holder<Object> holder = new Holder<>("abc");

Compilation fails with the following erro message:
Uncompilable source code - incompatible types
  required: javax.xml.ws.Holder<java.lang.Object>
  found:    javax.xml.ws.Holder<java.lang.String>


REPRODUCIBILITY :
This bug can be reproduced always.

EVALUATION This is a well-know limitation of the diamond inference scheme and of generic-method type-inference in general, which has been discussed and described in greater details here: http://mail.openjdk.java.net/pipermail/coin-dev/2009-August/002159.html Diamond inference re-uses the same inference machinery available for generic method inference; that is, it is possible to write an example without diamond that reproduces the very same problem: static <Z> Holder<Z> factory(Z z) { return new Holder<Z>(z); } Holder<Object> ho = factory("Hello!"); //error - expected Holder<Object> found Holder<String> As shown in the analysis, there are a number of cases (roughly 10%) in which diamond inference is not effective and therefore explicit parameters should be specified. An alternative is to use either Holder<?> or Holder<String> as the declared type of the variable (if that's possible).

10-11-2011