Please use the Apache issue tracking system for new NetBeans issues ( !!
Bug 248162 - Applying "redundant type arguments in new expression (use diamond operator instead)" hint leads to compiler error
Applying "redundant type arguments in new expression (use diamond operator in...
Product: java
Classification: Unclassified
Component: Hints
PC Windows 7
: P2 (vote)
: Dev
Assigned To: Svata Dedic
Depends on:
  Show dependency treegraph
Reported: 2014-10-24 03:13 UTC by _ gtzabari
Modified: 2016-11-11 02:50 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT


Note You need to log in before you can comment on or make changes to this bug.
Description _ gtzabari 2014-10-24 03:13:52 UTC
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 It's not clear whether this is a bug in Netbeans or the JDK, but one of them is definitely wrong.
Comment 1 amituser 2015-03-24 15:52:18 UTC
Any update on this issue ? Clearly this is a problem and it's priority needs to be bumped up for analysis.
Comment 2 Svata Dedic 2016-08-05 10:56:53 UTC
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.
Comment 3 Svata Dedic 2016-08-09 08:29:50 UTC
Lahvaci please advise if there's a way how could I detect the situation and raise a warning for the user.
Comment 4 _ gtzabari 2016-08-09 14:56:23 UTC

Are you sure that Lahvaci is CCed on this issue? (Doesn't look like it, judging by the CC list)
Comment 5 Svata Dedic 2016-11-04 14:27:07 UTC
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.
Comment 6 Quality Engineering 2016-11-11 02:50:30 UTC
Integrated into 'main-silver', will be available in build *201611110001* on (upload may still be in progress)

User: Svata Dedic <>
Log: #248162: suppressed hint for JDK < 9, if using diamond operator might lead to compile error

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo