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.

Bug 107071 - Add ClassPath.BOOT_EXECUTE
Summary: Add ClassPath.BOOT_EXECUTE
Status: NEW
Alias: None
Product: java
Classification: Unclassified
Component: Classpath (show other bugs)
Version: 6.x
Hardware: All All
: P2 blocker (vote)
Assignee: Tomas Zezula
Keywords: API
Depends on:
Blocks: 186747 206196
  Show dependency tree
Reported: 2007-06-18 19:46 UTC by Jesse Glick
Modified: 2012-01-25 20:56 UTC (History)
2 users (show)

See Also:
Exception Reporter:


Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Glick 2007-06-18 19:46:36 UTC
It might be nice for module projects, esp. in, 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

2. Probably as a separate dependent issue, I need to change apisupport to permit a separate JDK for running, and report
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.
Comment 10 Jesse Glick 2012-01-25 20:56:30 UTC
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.