JDK-8216383 : Remove the system property "java.vendor.version"
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.lang
  • Priority: P3
  • Status: Resolved
  • Resolution: Won't Fix
  • Submitted: 2019-01-08
  • Updated: 2019-06-05
  • Resolved: 2019-06-05
Related Reports
Relates :  
JDK-8197927 - Allow the system property `java.vendor.version` to be undefined
Description
The "java.vendor.version" system property was introduced by JEP 322 (Time-Based Release Versioning) as a way for a JDK implementor to provide additional version information [1].  Oracle used this property in JDK 10 and 11, but stopped using it as of JDK 12.  There is no evidence that any other JDK implementor ever used this property.  It no longer serves any useful purpose, so we should remove it.

[1] https://openjdk.java.net/jeps/322#System-properties
Comments
Given that people have found this property useful, I see no harm in keeping it. I'll close this as WNF and reopen JDK-8197927.
05-06-2019
As for the initial assumption: "There is no evidence that any other JDK implementor ever used this property" we can now state that: - Azul/Zulu uses it - Amazon/Corretto uses it - AdoptOpenJDK uses it We as SapMachine would be willing to use the property, too, if it'll be accepted as the de-facto standard for downstream OpenJDK binaries. Having said that, I propose to close this issue as Won't fix. Mark, what's your take?
03-04-2019
If we decide to not remove "java.vendor.version" system property we'll have to reopen and resolve JDK-8197927 as well.
02-04-2019
For JDK 11, Zulu uses the java.vendor.version property as per JEP 322. It shows in the -version output. It provides programs with a consistent programmatic way to report on the specific version of the JDK they are running on, and allows us to have the java.vm.version track the OpenJDK project's related version and build notions while still being to clearly and properly identify the specific binary we are on. Prior to JEP 322, we had identified versions in the version string, but there was no documented property to populate that programs could use. With JEP 322, the version string format itself became better defined, and AFAICT the java.vendor.version property's value is the only portion of that version string (per JEP 322) that is appropriate for that information. For future releases, we would like to retain a mechanism that would provide that (a version property separate from java.vm.version, and that appears in a specified place in the java -version output). Either in its current form per JEP 322, or in some alternate way that we can shift to. Example output and property settings of both Oracle Java 11 and Zulu 11 below: Lumpy.local-25% /Library/Java/JavaVirtualMachines/jdk-11.0.2.jdk/Contents/Home/bin/java -version java version "11.0.2" 2018-10-16 LTS Java(TM) SE Runtime Environment 18.9 (build 11.0.2+7-LTS) Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.2+7-LTS, mixed mode) Lumpy.local-26% /Library/Java/JavaVirtualMachines/jdk-11.0.2.jdk/Contents/Home/bin/java -XshowSettings:properties -version | & grep vendor.version java.vendor.version = 18.9 Lumpy.local-27% Lumpy.local-27% Lumpy.local-27% Lumpy.local-27% /Library/Java/JavaVirtualMachines/zulu-11.jdk/Contents/Home/bin/java -version openjdk version "11.0.2" 2019-01-15 LTS OpenJDK Runtime Environment Zulu11.29+3-CA (build 11.0.2+7-LTS) OpenJDK 64-Bit Server VM Zulu11.29+3-CA (build 11.0.2+7-LTS, mixed mode) Lumpy.local-28% /Library/Java/JavaVirtualMachines/zulu-11.jdk/Contents/Home/bin/java -XshowSettings:properties -version | & grep vendor.version java.vendor.version = Zulu11.29+3-CA
06-02-2019
Amazon also plans to use java.vendor.version for the upcoming Corretto 11 distro, so +1 to Gil's comment.
06-02-2019