Product Version: NetBeans IDE Dev (Build 201410160001)
Java: 1.8.0_20; Java HotSpot(TM) 64-Bit Server VM 25.20-b23
Runtime: Java(TM) SE Runtime Environment 1.8.0_20-b26
System: Windows 7 version 6.1 running on amd64; Cp1252; en_CA (nb)
User directory: C:\Users\Gili\AppData\Roaming\NetBeans\dev
Cache directory: C:\Users\Gili\AppData\Local\NetBeans\Cache\dev
MultivaluedMap<String, String> foo = new MultivaluedHashMap<>();
MultivaluedMap<String, String> bar = new MultivaluedHashMap<String, String>(foo);
where MultivaluedMap is defined by JAX-RS 2.0.1,
1. Netbeans flags the second line with a warning: "redundant type arguments in new expression (use diamond operator instead)."
2. If the hint is applied the second line becomes: MultivaluedMap<String, String> bar = new MultivaluedHashMap<>(foo);
3. This results in a compiler error:
reference to MultivaluedHashMap is ambiguous
both constructor <K,V>MultivaluedHashMap(MultivaluedMap<? extends K,? extends V>) in MultivaluedHashMap and constructor <K,V>MultivaluedHashMap(Map<? extends K,? extends V>) in MultivaluedHashMap match
where K,V are type-variables:
K extends Object declared in class MultivaluedHashMap
V extends Object declared in class MultivaluedHashMap
This is similar to http://stackoverflow.com/q/26222510/14731. It's not clear whether this is a bug in Netbeans or the JDK, but one of them is definitely wrong.
Any update on this issue ? Clearly this is a problem and it's priority needs to be bumped up for analysis.
In the current dev version, the issue is even more peculiar: the internal compiler (derived from JDK9 compiler) correctly infers the type arguments, while _commandline_ compiler (incl. Ant build)
The internal compiler is more permissive even though the project is set up to build with JDK8.
Lahvaci please advise if there's a way how could I detect the situation and raise a warning for the user.
Are you sure that Lahvaci is CCed on this issue? (Doesn't look like it, judging by the CC list)
I've suppressed the hint in jet-main#a4c89f2af4df
However the opposite (diamond operator in the source, which would lead to compile error) is not and will probably never be fixed.
Reason: The compiler in earlier JDKs use different implementation for diamond inference, that is difficult to recreate in nbjavac library (which is based on JDK9 with better capabilities). I was not able to reliably / effectively and *precisely* identify the bad cases. The fix mentioned above is rough in the sense it may suppress some valid hints - and the algorithm cannot be used to generate errors since it could introduce false positives. Sorry.
Integrated into 'main-silver', will be available in build *201611110001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
User: Svata Dedic <email@example.com>
Log: #248162: suppressed hint for JDK < 9, if using diamond operator might lead to compile error