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.
|Product:||java||Reporter:||Jesse Glick <jglick>|
|Component:||Classpath||Assignee:||Tomas Zezula <tzezula>|
|Issue Type:||ENHANCEMENT||Exception Reporter:|
|Bug Depends on:|
|Bug Blocks:||186747, 206196|
Description Jesse Glick 2007-06-18 19:46:36 UTC
It might be nice for module projects, esp. in nb.org, to permit you to use JDK 5 to compile but JDK 6 to run. This would be a simple change from the Ant side, but from the IDE side it would not work because ClassPath.BOOT as reported by apisupport is used for two kinds of purposes: 1. Compile-time bootcp, e.g. for background compiler, tasklist, code completion, etc. 2. Runtime bootcp, e.g. for debugger sourcepath, or stack trace hyperlinking. A hack would be to have clients of BOOT as in #2 check whether EXECUTE contains e.g. java/lang/Object.class, and if so, ignore BOOT. But this is perhaps too magical. Cleaner would be to introduce a new classpath type, BOOT_EXECUTE; clients of the 2nd type would be changed to look for this and use it in place of BOOT. Old clients would be unaffected. apisupport/project would report it always, perhaps different from BOOT.
Comment 1 Tomas Zezula 2007-06-18 19:53:52 UTC
The only question is if the ClassPath.getClassPath (fo, BOOT_EXECUTE) should return null or ordinary BOOT classpath if the ClassPathProvider returns null for BOOT_EXECUTE. Returning null allows clients to determine this case but in most (maybe all) cases they will just call getClassPath (BOOT). Returning BOOT classpath will be simpler for them.
Comment 2 Jesse Glick 2007-06-18 19:55:06 UTC
I agree that returning BOOT if CPP returns null for BOOT_EXECUTE would make sense. Isn't it too late to put this into NB 6? We are after feature freeze.
Comment 3 Jiri Prox 2008-04-11 00:52:53 UTC
moving opened issues from TM <= 6.1 to TM=Dev
Comment 4 Jesse Glick 2008-06-04 21:37:48 UTC
Do you still plan to do this for 6.5?
Comment 5 Tomas Zezula 2008-06-05 07:17:30 UTC
Yes, it's trivial.
Comment 6 Jesse Glick 2008-06-05 14:31:58 UTC
Well, adding the constant (and even a special behavior to getClassPath) is trivial. Then 1. All uses of CP.BOOT need to be reviewed. Those relating to execution rather than compilation need to be changed to BOOT_EXECUTE. 2. Probably as a separate dependent issue, I need to change apisupport to permit a separate JDK for running, and report this as BOOT_EXECUTE.
Comment 7 Jesse Glick 2008-11-12 17:36:28 UTC
This is important, please evaluate. I am sick of being forced to run the IDE in test mode under JDK 5 (or give up on having JDK source associations work well).
Comment 8 Tomas Zezula 2008-11-12 18:17:47 UTC
Adding constant is OK. The second step is a bit more difficult. As far as I know only ActionProvider and BinaryForSourceQuery are using execution boot cp. Are there any others?
Comment 9 Jesse Glick 2008-11-13 00:34:33 UTC
I'm not sure what you mean about "ActionProvider and BinaryForSourceQuery". Step #0 would be adding the constant, and perhaps changing ClassPath.getClassPath to make BOOT_EXECUTE default to BOOT. After that, my step #1 was to look for users of BOOT and replace with BOOT_EXECUTE. In particular, 1a. The debugger should pay attention to this when deciding what sources to make available for stepping into. I have not managed to locate this code. SourcePathProviderImpl looks for a property "jdksources" but it is not clear to me who sets this. I can't find any usage of CP.BOOT in debugger code at all. I think <nbjpdastart> can define a bootcp, but the NBM harness currently does not seem to do this, and it is not clear if it is necessary. 1b. JavaAntLogger already looks at the real bootclasspath for a running <java> process. This will not help in the case of NetBeans running, however, because this is not launched using <java>; it is not obvious to me now if it will use the default platform, or whatever is in GlobalPathRegistry. If the latter, then I guess GPR needs to prefer BOOT_EXECUTE to BOOT. Or JAL could be enhanced to specially support NB platform execution, looking for the diagnostics that NB prints during startup giving its JDK location. My step #2 can be done in parallel. It means that apisupport needs 2a. A new property supported in the harness for JDK to use when running the platform (and when running tests I guess). 2b. Some kind of GUI to configure this property, by default tied to the compile JDK, but possible to change independently. 2c. ClassPathProviderImpl (and perhaps NbModuleProject.OpenedHook) made to register BOOT_EXECUTE.