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.
| Summary: | Add ClassPath.BOOT_EXECUTE | ||
|---|---|---|---|
| Product: | java | Reporter: | Jesse Glick <jglick> |
| Component: | Classpath | Assignee: | Tomas Zezula <tzezula> |
| Status: | NEW --- | ||
| Severity: | blocker | CC: | issues, tzezula |
| Priority: | P2 | Keywords: | API |
| Version: | 6.x | ||
| Hardware: | All | ||
| OS: | All | ||
| Issue Type: | ENHANCEMENT | Exception Reporter: | |
| Bug Depends on: | |||
| Bug Blocks: | 186747, 206196 | ||
|
Description
Jesse Glick
2007-06-18 19:46:36 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. 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. moving opened issues from TM <= 6.1 to TM=Dev Do you still plan to do this for 6.5? Yes, it's trivial. 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. 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). 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? 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. Also desirable for certain startup arg providers (as in bug #206196) to know which boot classpath the project will be run with, which might be distinct from the compile-time bootcp. |