Bugzilla – Full Text Bug Listing
| Summary: | need a way to configure java home when using batch compiler Main in-process | ||
|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Jan Sievers <jan.sievers> |
| Component: | Core | Assignee: | Jay Arthanareeswaran <jarthana> |
| Status: | VERIFIED FIXED | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P2 | CC: | akurtakov, christian.dietrich.opensource, daniel_megert, jarthana, manoj.palat, sarika.sinha, stephan.herrmann |
| Version: | 4.8 | ||
| Target Milestone: | 4.8 M7 | ||
| Hardware: | All | ||
| OS: | All | ||
| See Also: | https://bugs.eclipse.org/bugs/show_bug.cgi?id=528905 | ||
| Whiteboard: | |||
| Bug Depends on: | |||
| Bug Blocks: | 514471 | ||
|
Description
Jan Sievers
Manoj or Jay, please work on this. If it's just making the setJavaHome public, the fix should be straight forward, as Tycho already uses this internal class anyway. I will work on this for M5. (In reply to Jay Arthanareeswaran from comment #2) > If it's just making the setJavaHome public, the fix should be straight > forward, as Tycho already uses this internal class anyway. I will work on > this for M5. I'm afraid there's a little more to it, see bug 514471 comment 52 Elsewhere there was mention that early JDKs don't have the expected "release" file (bug 528905 comment 14 onward), which also may have impact on this API, not sure. Jan is probably in a better position to describe the current state of the art. (In reply to Stephan Herrmann from comment #3) > (In reply to Jay Arthanareeswaran from comment #2) > > If it's just making the setJavaHome public, the fix should be straight > > forward, as Tycho already uses this internal class anyway. I will work on > > this for M5. > > I'm afraid there's a little more to it, see bug 514471 comment 52 > > Elsewhere there was mention that early JDKs don't have the expected > "release" file (bug 528905 comment 14 onward), which also may have impact on > this API, not sure. > > Jan is probably in a better position to describe the current state of the > art. yes unfortunately looks to me like it's not that easy. Main.setJavaHome() only works for JDKs >= 7 and after having a closer look, there are places where System.getProperty() is used to determine the bootclasspath, so it looks like the code assumes we want to compile against the JDK currently running. The method org.eclipse.jdt.internal.compiler.util.Util.collectPlatformLibraries(File javaHome) looked promising to me https://github.com/eclipse/eclipse.jdt.core/blob/3c7b09999b4c547cf6cdc2269b322f8997d9f385/org.eclipse.jdt.core/compiler/org/eclipse/jdt/internal/compiler/util/Util.java#L1171 but it looks to me like it does not really use the javaHome passed as parameter (and it's internal). E.g. using Java 8, it will always collect the bootclasspath of the currently running VM regardless of the javaHome dir passed in as parameter Using Java 9, it will return a single instance of org.eclipse.jdt.internal.compiler.batch.ClasspathJrt (In reply to Jan Sievers from comment #4) > but it looks to me like it does not really use the javaHome passed as > parameter (and it's internal). > > E.g. using Java 8, it will always collect the bootclasspath of the currently > running VM regardless of the javaHome dir passed in as parameter Unfortunately, as you said, the boot classpath is always fetched from the current JRE. For the other libraries, though, you can see java home is being used. (In reply to Jan Sievers from comment #0) > Alternatively Tycho could also use -bootclasspath CLI argument and do all > the scanning for JDK jars/modules by itself this is what we ended up doing by spawning a LibraryDetector VM https://git.eclipse.org/r/#/c/115711/ So, Tycho built the fix in their own code. And the fix in JDT Core looks not easy anyway. Do we still need this bug report? problem is solved as far as Tycho is concerned |