Community
Participate
Working Groups
Build Identifier: 3.6 If an Eclipse-based product bundles a JDK, it should be possible to point to an endorsed directory other than the default JDK's jre/lib/endorsed. Supporting this via the system property java.endorsed.dirs in eclipse.ini would be one way for a product to specify such a directory. Reproducible: Always Steps to Reproduce: 1. Configure Eclipse with a JDK. 2. Try to add an endorsed directory other than the JDK's jre/lib/endorsed (which is the default)
The behavior we observe today is that any jars in directories outside the JDK's jre/lib/endorsed are not picked up. We have tried specifying the JVM property: java.endorsed.dirs to point to a different directory and, although the VM property is set according to the Help => About => Installation Details => Configuration, the actual jars are not picked up by the configured JRE. If we create a Java project with this JRE, the jars do not show up in the package explorer.
Move to JDT/Debug
Marking as an enhancement request. The system property is a runtime property, and as such has not been picked up by the tooling at compile time. The jars/libs need to appear on the build path as well as the runtime class path. Support needs to be added to look for this property in the VM specific arguments and update when it changes.
We would also like a programmatic API to do this when creating an installed JRE.
We'd like to associate this with a specific JRE.
There is an alternate approach that could be used to define a JRE with endorsed directories that will appear properly on the build and runtime classpath: JDT supports defining installed JREs via "executable environment description" files (http://wiki.eclipse.org/Execution_Environment_Descriptions). There is also an API to create/define VMs from description files: org.eclipse.jdt.launching.JavaRuntime.createVMFromDefinitionFile(File, String, String) These description files support the notion of endorsed directories via the "ee.endorsed.dirs" property in a description file. A client could define/ship an "ee" file that describes the desired JRE (with custom endorsed directories). The client could programmatically create an installed JRE from the file with existing API.
Created attachment 177141 [details] patch work in progress
We are evaluating and trying things out based on Darin's on comment #6. We'll post the result once we have got the results.
Darin suggestion possibly works but I found a different solution which I think is simpler to implement. Instead of creating a .ee file and maintain it (creating the file and its properties, updating the properties if needed, deleting the file) one could get the libraries from the VM, and append or re-arrange libraries as it is needed and set them on the VM back. This implies that one needs create LibraryLocation objects from the libraries provided in the proprietary endoresed dir and append them to the top of all libraries - This is probably be less work, than maintain a file. - It should be faster, as there is no IO during creation and reading of a ee. file, everything is done in memory, and - For most of the work there are APIs already provided.
No longer in plan for 3.7 as the workaround described in comment#9 is sufficient.
