Temurin-build: jdk12 openj9 builds should return vendor=Eclipse OpenJ9

[smlambert]

Platform:
All

Architecture:
All

Please describe the issue that you are having with our binaries and if possible how to recreate it.
openj9 jdk8 & jdk11 behaviour:
System.getProperty(‘java.vm.vendor’)=Eclipse OpenJ9

while jdk12 returns:
System.getProperty(‘java.vm.vendor’)=AdoptOpenJDK

This should get corrected, so we can differentiate between implementations built at Adopt (and auto-detect JDK_IMPL during testing). May be other reasons, beside potential test differentiation to need an easy way to check which implementation has been built (hotspot, openj9, corretto, sapmachine, etc).

[lumpfish]

The new jdk12 properties are:
java.runtime.name = OpenJDK Runtime Environment
java.runtime.version = 12+32-201903040957
java.specification.name = Java Platform API Specification
java.specification.vendor = Oracle Corporation
java.specification.version = 12
java.vendor = AdoptOpenJDK
java.vendor.url = https://adoptopenjdk.net/
java.vendor.url.bug = https://github.com/eclipse/openj9/issues
java.vendor.version = AdoptOpenJDK
java.version = 12
java.version.date = 2019-03-19
java.vm.info = JRE 12 Linux amd64-64-Bit Compressed References 20190304_20 (JIT enabled, AOT enabled)
OpenJ9 - dff29d8c2
OMR - 89f2015f
JCL - 3371a09453 based on jdk-12+32
java.vm.name = Eclipse OpenJ9 VM
java.vm.specification.name = Java Virtual Machine Specification
java.vm.specification.vendor = Oracle Corporation
java.vm.specification.version = 12
java.vm.vendor = AdoptOpenJDK
java.vm.version = master-dff29d8c2

The latest jdk11 release properties are:
java.runtime.name = OpenJDK Runtime Environment
java.runtime.version = 11.0.2+9
java.specification.name = Java Platform API Specification
java.specification.vendor = Oracle Corporation
java.specification.version = 11
java.vendor = Eclipse OpenJ9
java.vendor.url = http://www.eclipse.org/openj9
java.vendor.version = AdoptOpenJDK
java.version = 11.0.2
java.version.date = 2019-01-15
java.vm.info = JRE 11 Linux amd64-64-Bit Compressed References 20190204_127 (JIT enabled, AOT enabled)
OpenJ9 - 90dd8cb40
OMR - d2f4534b
JCL - 289c70b6844 based on jdk-11.0.2+9
java.vm.name = Eclipse OpenJ9 VM
java.vm.specification.name = Java Virtual Machine Specification
java.vm.specification.vendor = Oracle Corporation
java.vm.specification.version = 11
java.vm.vendor = Eclipse OpenJ9
java.vm.version = openj9-0.12.1

[lumpfish]

It seems to me that these jdk12 properties are correct:

java.vendor = AdoptOpenJDK
java.vendor.url = https://adoptopenjdk.net/

but are incorrect in jdk11:

java.vendor = Eclipse OpenJ9
java.vendor.url = http://www.eclipse.org/openj9

[lumpfish]

And that this is incorrect in jdk12:

java.vm.vendor = AdoptOpenJDK

but correct in jdk11:

java.vm.vendor = Eclipse OpenJ9

[lumpfish]

And that this new property in jdk12 needs discussion as to whether the value is correct:

java.vendor.url.bug = https://github.com/eclipse/openj9/issues

[lumpfish]

@smlambert - was your expectation that java.vendor should be Eclipse Openj9 based on the fact that that is what it is in jdk11 or was there some previous discussion which concluded that was the correct value? @karianna - similar question - do you have an expectation for the java.vendor system property value for AdoptOpenJDK builds?

[smlambert]

I am not sure what is the right approach, definitely could use discussion. I know that I may want to differentiate between different implementations built at AdoptOpenJDK somehow. If we build a hotspot build, an openj9 build, a corretto build and a sapmachine build, is there an easy way for me to tell them apart, if we set AdoptOpenJDK for vendor for all of them?

Looks like we could use java.vm.name to query for openj9. FYI @llxia

What properties differentiate corretto and sapmachine builds?

[karianna]

We will have to be very careful about the builds we produce on behalf of others. It'll be down to trademark usage in each case.

[lumpfish]

There is a request to remove java.vendor.version, btw: https://bugs.openjdk.java.net/browse/JDK-8216383

[andrew-m-leonard]

This Wikipedia entry adds to the confusion lists both AdoptOpenJDK and Eclipse OpenJ9 https://en.wikipedia.org/wiki/List_of_Java_virtual_machines

[lumpfish]

This is some discussion from Corretto: https://github.com/corretto/corretto-8/issues/3.
This particular comment lists the java.vendor from a number of jdks: https://github.com/corretto/corretto-8/issues/3#issuecomment-447242114.
The anomaly again seems to be openjdk11-openj9, where Eclipse Openj9 is the java.vendor rather than AdoptOpenJDK.
Using the definition of java.vendor as the Java Runtime Environment vendor suggests to me that if Corretto were to be built at AdoptOpenJDK, AdoptOpenJDK should be the java.vendor there too. A user could then be confident of the origin of his / her jdk / jre.

[karianna]

FWIW I agree with @lumpfish analysis of the changes required for 11 and 12 - I personally feel the vendor bug URL should come to adopt first.

[andrew-m-leonard]

Raised OpenJ9 issue: https://github.com/eclipse/openj9/issues/5002

[smlambert]

For the record, at the present time it is sufficient for us to use the current value of java.vm.name to differentiate, and I agree that java.vm.vendor can be the org that built it, in other words AdoptOpenJDK. But I am glad that there is a discussion about this, to make sure we get it right for all implementions that may be built out of the Adopt build farm.

[lumpfish]

I don't think anyone has an issue with java.vm.vendor being Eclipse OpenJ9 - the issue @andrew-m-leonard raised (eclipse/openj9#5002) should fix that. It's just that while investigating I saw that java.vendor (as opposed to java.vm.vendor) is different between openjdk11-openj9 and openjdk12-openj9 as well. It is the value of java.vendor being set to AdoptOpenJDK in the AdoptOpenJDK jdk12 builds (which seems to me like the 'correct' value) which has caused the incorrect value in java.vm.vendor (eclipse/openj9 is copying the value of java.vendor to java.vm.vendor).

[smlambert]

FYI @llxia - let's hold off on changing implementation of AUTO_DETECT for now, until we see how this resolves, in the meantime I have updated the jdk12 test jobs at Adopt to disable AUTO_DETECT and set JDK_IMPL explicitly.

[lumpfish]

In addition to the openj9 fix the following code in https://github.com/AdoptOpenJDK/openjdk-build/blob/master/sbin/build.sh needs correcting:

    addConfigureArg "--with-vendor-version-string=" "AdoptOpenJDK"
    addConfigureArg "--with-vendor-url=" "https://adoptopenjdk.net/"
    addConfigureArg "--with-vendor-name=" "AdoptOpenJDK"
    addConfigureArg "--with-vendor-vm-bug-url=" "https://github.com/AdoptOpenJDK/openjdk-build/issues"

--with-vendor-vm-bug-url is incorrect - that should point to: https://github.com/eclipse/openj9/issues

--with-vendor-bug-url is missing - that should point to: https://github.com/AdoptOpenJDK/openjdk-build/issues

[lumpfish]

Although the openjdk build insists on a value for --with-vendor-vm-bug-url there is no corresponding property (java.vm.version.url.bug) listed by

java -XshowSettings:properties -version

by either openjdk-hotspot or openjdk-openj9

[lumpfish]

Submitted PR https://github.com/AdoptOpenJDK/openjdk-build/pull/955 to fix java.vendor.url.bug

[lumpfish]

Latest nightly build for openjdk12-openj9 now shows:

    java.vendor = AdoptOpenJDK
    java.vendor.url = https://adoptopenjdk.net/
    java.vendor.url.bug = https://github.com/AdoptOpenJDK/openjdk-build/issues
    java.vendor.version = AdoptOpenJDK
    java.version = 12
    java.version.date = 2019-03-19
    java.vm.info = JRE 12 Linux amd64-64-Bit Compressed References 20190311_29 (JIT enabled, AOT enabled)
OpenJ9   - df0e93637
OMR      - 5f74eb34
JCL      - 565a9bd3b8 based on jdk-12+32
    java.vm.name = Eclipse OpenJ9 VM
    java.vm.specification.name = Java Virtual Machine Specification
    java.vm.specification.vendor = Oracle Corporation
    java.vm.specification.version = 12
    java.vm.vendor = Eclipse OpenJ9
    java.vm.version = master-df0e93637

So @smlambert , the check for "java.vm.vendor=Eclipse OpenJ9" should now be working.

[smlambert]

Thanks, closing as resolved.