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 Retouche for the first time and opened a couple of nbdev module projects. It started indexing my JDK 5 binary install, fine (this is the bootcp for my NBM projects). Then I noticed it was trying to index my JDK 6 source tree for some reason - I am not sure why. UOE began to be thrown very fast. I had to kill the IDE.
Created attachment 35536 [details] Log file
The JDK 6 source tree was configured as a source association for my default platform. I don't know why that would matter, though - I only opened those two NBM projects, which both use an explicit JDK 5 platform, not the default platform. It should not have been scanning my default platform AFAIK, unless Retouche just always does that automatically. Anyway the primary problem is that a scan of JDK 6 sources dies, of course.
The retouche does not scan the default platform by default. It collects all the open projects and their dependencies. From the attached log it seems that you have a project which uses JDK 6.0 and the JavaPlatform is preconfigured with the following sources: Classpath: ClassPath[] Sourcepath: ClassPath[Entry[jar:file:/space/jdk1.6/src.zip!/], Entry[file:/space/src/jdk6/j2s e/src/share/classes/], Entry[file:/space/src/jdk6/j2se/src/solaris/classes/]]. The problem is that the javac tries to read the sources from the src.zip. It's strange that it does not use rt.jar. Can you attach the BOOT,COMPILE and SOURCE classpaths for /space/src/jdk6/j2se/src/share/classes?
The initial scan work in the following way: 1) It takes the GlobalPathRegistry.getClassPath(SOURCE) 2) Adds the GlobalPathRegistry.getClassPath (BOOT) translated to sources if possible. 3) Adds the GlobalPathRegistry.getClassPath (COMPILE) translated to sources if possbile. 4) It adds the dependent classpaths for classpaths got in steps 1-3 if they are not already added (recursively). 5)TopSort of source roots. 6) Compiles the source roots. If it tried to compile the JDK 6.0 it had to be either registered in the GPR or someone depends on it.
"Can you attach the BOOT,COMPILE and SOURCE classpaths for /space/src/jdk6/j2se/src/share/classes?" - not sure what you mean. All I had was this dir (also .../solaris/...) configured as a source association for my default Java platform in Java Platform Manager; it is not a project. Was fine under javacore for months. After I shut down the IDE, I deleted this entry from the platform .xml file manually and restarted and then the problem went away. Again, I did not open any project using JDK 6. I opened two NBM projects in my normal nbdev source tree, which is configured to use JDK 5 in user.build.properties. It seems to me that the IDE now tries to scan your default platform whether or not that is actually used by any open projects. Which is probably fine in general, though it is a change from javacore's behavior which surprised me.
OK, the JDK 6.0 platform had following sourcepath: jar:file:/space/jdk1.6/src.zip!/ file:/space/src/jdk6/j2se/src/share/classes/ file:/space/src/jdk6/j2se/src/solaris/classes/ Right? The initial scan doesn't use the default platform, but if someone registered its classpath into GPR then it would scan it. Are these NBM modules in the CVS? I want to find out from where the default platform came.
Yes, that was its sourcepath. /space/src/jdk6 is a checkout of https://jdk-jrl-sources.dev.java.net/svn/jdk-jrl-sources/jdk6/trunk. Note issue #87970 which might be cause of exceptions, I don't know. Looks like those projects *were* using the default platform after all - somehow my platform association for nb.org CVS got messed up, not sure how but probably my fault.
Thanks, now I understand what happened, it should be easy to fix the UOE.
Nope, this is reproducible even without Jackpot modules. I added those source roots back into my default Java platform and made a j2seproject using JDK 6. Started getting the same UOEs again. ALL [null]: Root: /space/src/jdk6/j2se/src/share/classes File: file:/space/src/jdk6/j2se/src/share/classes/sun/io/CharToByteISO8859_3.java Bootpath: ClassPath[Entry[file:/home/jglick/nbdev/var/cache/index/0.1/s44/classes/], Entry[file:/home/jglick/nbdev/var/cache/index/0.1/s45/classes/], Entry[file:/home/jglick/nbdev/var/cache/index/0.1/s44/classes/], Entry[file:/home/jglick/nbdev/var/cache/index/0.1/s45/classes/], Entry[file:/home/jglick/nbdev/var/cache/index/0.1/s44/classes/], Entry[file:/home/jglick/nbdev/var/cache/index/0.1/s45/classes/], Entry[file:/home/jglick/nbdev/var/cache/index/0.1/s44/classes/], Entry[file:/home/jglick/nbdev/var/cache/index/0.1/s45/classes/], Entry[file:/home/jglick/nbdev/var/cache/index/0.1/s44/classes/], Entry[file:/home/jglick/nbdev/var/cache/index/0.1/s45/classes/], Entry[file:/home/jglick/nbdev/var/cache/index/0.1/s44/classes/], Entry[file:/home/jglick/nbdev/var/cache/index/0.1/s45/classes/], Entry[file:/home/jglick/nbdev/var/cache/index/0.1/s44/classes/], Entry[file:/home/jglick/nbdev/var/cache/index/0.1/s45/classes/], Entry[file:/home/jglick/nbdev/var/cache/index/0.1/s44/classes/], Entry[file:/home/jglick/nbdev/var/cache/index/0.1/s45/classes/], Entry[file:/home/jglick/nbdev/var/cache/index/0.1/s44/classes/], Entry[file:/home/jglick/nbdev/var/cache/index/0.1/s45/classes/], Entry[file:/home/jglick/nbdev/var/cache/index/0.1/s44/classes/], Entry[file:/home/jglick/nbdev/var/cache/index/0.1/s45/classes/], Entry[file:/home/jglick/nbdev/var/cache/index/0.1/s44/classes/], Entry[file:/home/jglick/nbdev/var/cache/index/0.1/s45/classes/]] Classpath: ClassPath[] Sourcepath: ClassPath[Entry[jar:file:/space/jdk1.6/src.zip!/], Entry[file:/space/src/jdk6/j2se/src/share/classes/], Entry[file:/space/src/jdk6/j2se/src/solaris/classes/]]
Yes, it's not caused by the Jackpot. It is related to the sourcepath containing both folder and archive file. While javac compiles the sources from the folder it tries to resolve the types using the files from the zip file which caused the problem. Simply changing the order of the src.zip and jdk sources should help. I only wasn't sure why the JDK 6.0 was indexed when it wasn't used.
IDE: [10/26/06 10:44 AM] Committing "Java Source" started Checking in GlobalSourcePath.java; /cvs/java/source/src/org/netbeans/modules/java/source/classpath/GlobalSourcePath.java,v <-- GlobalSourcePath.java new revision: 1.3; previous revision: 1.2 done Checking in CacheClassPath.java; /cvs/java/source/src/org/netbeans/modules/java/source/classpath/CacheClassPath.java,v <-- CacheClassPath.java new revision: 1.3; previous revision: 1.2 done IDE: [10/26/06 10:44 AM] Committing "Java Source" finished