JEP 231: Remove Launch-Time JRE Version Selection
|Component||tools / launcher|
|Discussion||core dash libs dash dev at openjdk dot java dot net|
|Reviewed by||Alan Bateman, Joe Darcy, Neil Toda|
|Endorsed by||Brian Goetz|
Remove the ability to request, at JRE launch time, a version of the JRE that is not the JRE being launched.
The "Multiple JRE" ("mJRE") feature allows a developer to specify what
JRE version, or range of versions, can be used to launch an application.
The version-selection criteria can be specified in a manifest entry of
jar file (
JRE-Version) or as a command-line option
-version:) to the
java launcher. If the version of the JRE that is
launched does not satisfy the criteria then the launcher searches for a
version that does, and if it finds one then it launches that version.
Deploying an application, in practice, requires doing more than just selecting a particular JRE. Modern applications are typically deployed via Java Web Start (JNLP), native OS packaging systems, or active installers, and all of these technologies have their own ways of finding, and even sometimes installing and later updating, an appropriate JRE for the application.
The mJRE feature addresses only one part of the overall deployment
problem. It was, moreover, never fully documented when it was introduced
in JDK 5: The
-version: option is mentioned in the documentation
java command but the
JRE-Version manifest entry is not
mentioned in any of the usual JDK documentation, nor in the Java SE
Platform Specification. So far as we know, this feature was very rarely
used. It needlessly complicates the implementation of the Java launcher,
making it burdensome to maintain and enhance.
Remove the mJRE feature. Modify the launcher as follows:
Emit an error message and exit if the
-version:option is given on the command line, and
Emit a warning message and continue if the
JRE-Versionmanifest entry is found in a
The rationale for a warning rather than a fatal error in the second case
is that the manifest entry might be present in old
jar files which
cannot readily be modified, and so it's better to continue rather than
abort. We expect to change this case to a fatal error in JDK 10.
Testing is required to ensure that the feature is removed and the appropriate warnings and errors are reported.