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 started NetBeans with a clean cache (I deleted directory <NB-user-dir>/var/cache) and opened four NetBeans module projects. NetBeans started scanning the projects but the scanning does not progress beyond "openide.filesystems". These are the steps I did before I got to the state: 1) I had opened several NetBeans module projects in the IDE. I had installed three Java platforms in the IDE: JDK 1.5.0_18, JDK 6u13, JDK 6u14-ea-b06. 2) I closed all the projects. 3) I restarted the IDE. 4) I removed Java platforms JDK 1.5.0_18 and JDK 6u14-ea-b06 from the IDE (Tools > Java Platforms). 5) I closed the IDE. 6) I deleted JDK 1.5.0_18 and JDK 6u14-ea-b06 from the system. 7) I installed (by running a shell script) JDK 1.5.0_19 and JDK 6u14-FCS. Installation directory of JDK 1.5.0_19 was *different* from that of JDK 1.5.0_18. Installation directory of JDK 6u14-FCS was *the same* as that of JDK 6u14-ea-b06. 8) I started the IDE again. 9) I added Java platforms JDK 1.5.0_19 and JDK 6u14-FCS (Tools > Java Platforms). 10) I opened four NetBeans module projects ("Issue Tracking", "Issue Tracking Bridge Module", "Versioning" and "Versioning Support Utilities").
Created attachment 82974 [details] thread-dump 1
Created attachment 82975 [details] thread-dump 2
Created attachment 82976 [details] thread-dump 3
Created attachment 82977 [details] thread-dump 4
Created attachment 82978 [details] thread-dump 5
Created attachment 82979 [details] thread-dump 6
Created attachment 82980 [details] thread-dump 7
Created attachment 82981 [details] thread-dump 8
Created attachment 82982 [details] thread-dump 9
I found the following messages in the log file (messages.log): ---------------------------------------------------------------------------------------------------------------------- Even though the source level of /home/mp/sources/NetBeans/cdev/openide.filesystems/src is set to: 1.5, java.lang.AssertionError cannot be found on the bootclasspath: /usr/local/java/jdk1.5.0_18/jre/lib/rt.jar Changing source level to 1.3Even though the source level of /home/mp/sources/NetBeans/cdev/openide.filesystems/src is set to: 1.5, java.lang.AssertionError cannot be found on the bootclasspath: /usr/local/java/jdk1.5.0_18/jre/lib/rt.jar Changing source level to 1.3 ---------------------------------------------------------------------------------------------------------------------- "/usr/local/jdk1.5.0_18" is a path to the uninstalled JDK.
Product Version = NetBeans IDE 6.7 RC1 (Build 200905232021) Operating System = Linux version 2.6.26-1-amd64 running on amd64 Java; VM; Vendor = 1.6.0_14; Java HotSpot(TM) 64-Bit Server VM 14.0-b16; Sun Microsystems Inc. Runtime = Java(TM) SE Runtime Environment 1.6.0_14-b08 Java Home = /usr/local/java/jdk1.6.0_14/jre System Locale; Encoding = en_US (nb); UTF-8
The neverending scanning cannot be stopped, it even blocks closing the main window of the IDE. So I stopped the JVM by pressing Ctrl-C in the console. However, after startup, NetBeans restarted the scanning process and I ended up in the same situation. Deleting the cache (<nb-userdir>/var/cache) between shutdown and restart does not help either.
I solved the problem by manual update of file "<nb-sources>/nbbuild/user.build.properties".
"I solved the problem by manual update of file "<nb-sources>/nbbuild/user.build.properties"." - What exactly does this mean? Did your user.build.properties contain reference to the uninstalled JDK (eg. in nbjdk.home property)? If so, then I'd say we can close this report as INVALID.
Yes, it contained a reference to the uninstalled JDK. However, I do not think this is an invalid or trivial bug.
Well, what would you expect the IDE to do? IMO the scanning was just too slow and producing classes with a lot of errors.
I would expect the IDE to verify validity of the reference to the JDK. If the reference is invalid, either ask the user to fix it or use the default Java platform.
Reassigning all moonko's java/source bugs to myself.
Hm, seems this was buried under the heaps of other reports until now, but its time to bring it up again (it did happen again to our colleague). Summary: the bootclasspath reported from the project is broken, i.e. it does not contain essential classes like j.l.Object. Two aspects: -the Java infrastructure handles this situation better now - the scanning should be quite fast - it mostly does nothing. Seems to be this way since approx. Sep 2009. This is somewhat confusing, because it does not show any error badges in the projects tab, etc. - it will only show errors when a file is opened in the editor. tzezula is going to improve that by reporting one synthetic "missing platform" error for each of the indexed files, which hopefully won't make the performance much worse, but which should greatly improve the user experience. -the projects should always send a reasonable bootclasspath. If the JDK set-up in the project does not exist, it should automatically switch to the default platform. Ideally, it should also show a "broken project" badge&dialog. J2SE projects do both: send the default platform until the platform is corrected and show the broken project badge and dialog. In fact, apisupport projects switch to the default platform for build if the preset platform does not exist, so this is also build-time vs. IDE-time inconsistency, which would need to be fixed on its own anyway. Passing to the apisupport/project to ensure that the project bootclasspath is always sane (and consistent with the ant build).
Can do that. No plans to implement a "broken platform" badge for apisupport.ant. Workaround should simply be to set the desired platform on the project.