Build: NetBeans IDE 7.0.1 (Build 201107282000)
VM: Java HotSpot(TM) Client VM, 21.0-b17, Java(TM) SE Runtime Environment, 1.7.0-b147
bondolo: java 8 lambda source
Created attachment 109990 [details]
Created attachment 110457 [details]
Created attachment 110458 [details]
Hard to fix without a reproducible test case. Are you able to reproduce the
issue? If so, could you please create a simple test case and attach it to the
You can use the j2se netbeans project which is part of the openjdk lambda project (http://hg.openjdk.java.net/lambda/lambda/jdk/). Unfortunately the error message doesn't give context to where the error is generated so I can't be more specific as to where the error is located.
Created attachment 114737 [details]
Created attachment 146557 [details]
opened jni.h file
Created attachment 148074 [details]
Background scanning I guess.
Created attachment 149258 [details]
(In reply to Dusan Balek from comment #4)
> Hard to fix without a reproducible test case.
Surely you could start by making the assertion statement assert something specific about what is wrong? This exception happens to me on a more or less daily basis so it would not be long before you got some more details.
In(In reply to Jesse Glick from comment #10)
> (In reply to Dusan Balek from comment #4)
> > Hard to fix without a reproducible test case.
> Surely you could start by making the assertion statement assert something
> specific about what is wrong? This exception happens to me on a more or less
> daily basis so it would not be long before you got some more details.
Indeed. This can still be trivially replicated with the j2se netbeans project in openjdk jdk8-dev. The Netbeans projects for JDK9 are different because of jigsaw modularization.
Still happening four years later in a 20150921 dev build. Regardless of whether it is reproducible, an AssertionError with no detail message to continue diagnosis is something that should be fixed.
I have been able to replicate this fairly easily by switching between VCS branches without recompiling. It seems to be related to a mismatch between the anonymous inner classes declared by the source vs the compiled bits vs the previously scanned source. Usually a "Clean and Build" will help resolve the problem but on occasion I have to blow away the scanned project cache:
rm -rf ~/Library/Application\ Support/NetBeans/8.1beta/var/log/* ~/Library/Caches/NetBeans/8.1beta/
Upon restarting the IDE things are generally much happier.
This is still rather annoying. Switching between git/hg branches using the same workspace should be smarter about clearing project scan caches.
Created attachment 158567 [details]
82 reports => P1