Community
Participate
Working Groups
Build ID: eclipse-SDK-4.7rc2 As an organization shipping Eclipse without a bundled JRE, I want the Eclipse Launcher to run with any JRE on the market such that my product can be deployed universally. As an Eclipse developer, I want a generic data-driven mechanism in the compiled equinox launcher, such that even future JREs not yet anticipated at the time of release can be supported without recompiling the launcher. Background and Design Proposal: =============================== Over time, a couple of different Java Runtimes have come up which need special arguments to properly run Eclipse, most noteworthy: * MacOSX needs the -XstartOnFirstThread * Java 9 needs special options for Jigsaw, which Java 8 fails on * Some IBM JREs need different options than Oracle Given the issues we've seen around re-compiling the Launcher in Oxygen M7 and reverting back due to late issues seen, it's time to make this data driven. Here is a simple proposal: 1. The launcher detects the JRE and computes an ID string from it -- could be a hash of the "java --version" output, or a lookup of that version in a table 2. Given the Java ID String, the Launcher first tries to load "launcher-javaID.ini" and if that is not found next to the launcher itself, it falls back to "launcher.ini" same as today. Assuming that we can come up with a reasonable way computing a "Java ID" from the JRE that was detected, this mechanism would simplify the launcher and make it future proof. Acceptance Criteria: -------------------- A. MUST detect the most relevant Java 9 EAR JRE's and derive a suitable "JRE ID" from them, such that a single launcher can work with both Java 8 (standard .ini) and Java 9 (special flags). Complexities / Discussion of the Proposal: ------------------------------------------ 1. For (1) above, derive a "JRE ID" that is independent of the patchlevel or other details, yet sufficiently identify the JRE; might require some regex text processing or Platform-dependent way extracting the Vendor and Major Version of the JRE from its program output, executable image or install location). Must also be independent of translations (i18n and g18n). 2. As an alternative to (2) above, the Launcher could also try reading all launcher-*.ini that it finds in its install directory, and read a property (Regex Pattern?) from that .ini which it then matches against the "java -version" output. If that Regex Pattern can also include newlines, or newlines are first translated into some other character, that mechanism would be even more universal. 3. Having multiple launcher.ini's in the startup directory may not look as clean as desired. Allowing a *single* launcher.ini with some kind of an "if..." mechanism to enable certain settings only for certain JREs might be a preferrable approach. Still, that approach also requires solving the complexity of deriving a "JRE ID String" from the discovered JRE. Related Work: ============= * http://eclip.se/12345 All "Equinox Launcher" unresolved tickets with "ini" in the summary
