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.
Based of issue #165742, it would be nice if the J2SE Project allowed modifications of the boot classpath (i.e. prepending/appending something on boot CP). Considering the #165742 usecase, it would be ideal if the output of the J2SE project could be automatically prepended on the boot CP.
(1) User has some idea, how modify class in JDK, let's say Boolean.java. So user copies the original source of Boolean.java into project's src folder. Then he makes his changes and build's the project. Wow, user is happy, as he can hack JDK classes without any special requirements and settings. (reason: IDE doesn't prepend JDK's sources automatically for good reason) (2) From the positive experience of (1), now user runs his project, to check the effect of his modifications. Unhappy, because of errors: - java.lang.SecurityException: Prohibited package name: java.lang - Could not find the main class: java.lang.Run. Program will exit. Ok, first move class Run to other package: myhome.Run. Next error: - java.lang.NoSuchMethodError: java.lang.Boolean.valueOf(I)Ljava/lang/Boolean Ok, thinking about that, user tries run.jvmargs= -Xbootclasspath/p\:${build.classes.dir} Wow, user is happy, as he can run hacked JDK classes with little setting. (3) From the positive experience of (2), now user likes to define JUnit tests for his hack, let's say BooleanTest. Unhappy, because it does not run, and wondering, that BooleanTest doesn't compile, because there was no problem indicated by IDE's auto-compile: cannot find symbol symbol : method valueOf(int) location: class java.lang.Boolean assertTrue(Boolean.valueOf(1)); ... now I have to look for my kid, sorry, see you tomorrow
Re (1) "(reason: IDE doesn't prepend JDK's sources automatically for good reason)": sorry, but I fail to see how this relates to JDK sources. The ant build simply puts all source files for which there is not an up-to-date classfile in build/classes to the compiler's command line. The compiler always compiles all the source files it gets in the command line regardless any classfiles it finds. Not related to the IDE, IMO, and not sure how this relates to a runtime boot classpath. Anyway, as I said in issue #165742, contributions are welcome.
Jan, my analogy was not good as I thought. I tried to compare with the theoretical "compile-classpath": - sources in compiler's command line - classes in build/classes - JDK classes against runtime classpath: - main class - Xbootclasspath (here = classes in build/classes) - JDK classes (- classes in build/classes) against debug sources classpath: - JDK classes - classes in build/classes (includes main class) against compile test classpath: - main class - JDK classes - classes in build/classes - classes in test/build/classes against test classpath: - main class - Xbootclasspath (here = classes in build/classes) - JDK classes (- classes in build/classes) - classes in test/build/classes against debug test sources classpath: - JDK classes - classes in build/classes - classes in test/build/classes (includes main class) The problem for the user is, that runtime classpath and test/debug classpath are not the same. > Not related to the IDE Hm, in my understanding IDE determines the ant build script, and the ant run/test/debug script.
Suggestion: - If special IDE option enabled, IDE should scan project sources for JDK package names, and add them to automatically added -Xbootclasspath option (don't forget choice between none, /p: and /a:). Those paths should be derived to debug + test scenarios. - JUnit test environement should have adequate access rights.
Now there comes some little support from Issue 166801.