This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
I've got code which compiles with the Ant script (and parses without error in other IDEs), but the editor shows an error. Consider public static <K, V extends Keyable<K>> Map<K, V> asMap(Collection<? extends V> entries) { // returns a HashMap<K,V>; } and client code calling this method which uses Strings as keys. The editor will complain about incompatible types (found java.util.Map<java.lang.Object, foo> required java.util.Map<java.lang.String, foo>).
A bug in JDK - see http://bugs.sun.com/view_bug.do?bug_id=6650759
*** Issue 124008 has been marked as a duplicate of this issue. ***
*** Issue 139354 has been marked as a duplicate of this issue. ***
Since 6.5 beta doesn't seem to contain any changes... An interesting fact, somehow Eclipse team was able to implement a workaround (or whatever they did) since version 3.2. Thank you.
Afaik eclipse does not use javac. They have their own compiler with their own bugs :)
Still, it is surprising that this bug was allowed to linger so long in the jdk when the cause is known. Is the team aware that this development version of javac is being used in a production product? On the NB side, is it possible to trap the exception and ignore this particular error? Terrible, I know, but I think it's probably better for the editor to ignore the false error at the risk of missing a compilation error than have false error badges. The error would still be caught by the jdk5 or 6 compiler during the actual compilation through NB. This bug is pretty much going to prevent anyone at salesforce.com from using NB, that's for sure.
Well, in my own test case (see issue #139354) javac (invoked either during the regular project build in NB or via plain command line) is perfectly capable of compiling the code in question. If it is indeed a javac bug, then NB editor somehow manages to trigger it. And only NB editor is capable of triggering it. The bug does not manifest itself when I'm using javac directly. Very interesting javac bug...
Yes, that's because the editor uses the new javac API to introspect the abstract syntax tree, and this API is only available in java7. So, the editor uses the javac from java7, and the ant compile is using whatever version of java you've configured your IDE with. So, the editor is exposed to whatever bugs are in the pre-release compiler in java7.
Closing JDK bugs as WONTFIX.
Isn't it better to make them all a child of a master JDK bug, and when integrating a new version of the compiler/javac api into the editor, update that?