Temurin-build: File release has empty Source string: SOURCE=""

Created on 13 Feb 2019  ·  8Comments  ·  Source: adoptium/temurin-build

Platform:

Any

Architecture:

Any

If I look at the release file in 11.0.2 from AdoptOpenJDK

IMPLEMENTOR="AdoptOpenJDK"
IMPLEMENTOR_VERSION="AdoptOpenJDK"
JAVA_VERSION="11.0.2"
JAVA_VERSION_DATE="2019-01-15"
MODULES="java.base java.compiler java.datatransfer java.xml java.prefs java.desktop java.instrument java.logging java.management java.security.sasl java.naming java.rmi java.management.rmi java.net.http java.scripting java.security.jgss java.transaction.xa java.sql java.sql.rowset java.xml.crypto java.se java.smartcardio jdk.accessibility jdk.internal.vm.ci jdk.management jdk.unsupported jdk.internal.vm.compiler jdk.aot jdk.internal.jvmstat jdk.attach jdk.charsets jdk.compiler jdk.crypto.ec jdk.crypto.cryptoki jdk.crypto.mscapi jdk.dynalink jdk.internal.ed jdk.editpad jdk.hotspot.agent jdk.httpserver jdk.internal.le jdk.internal.opt jdk.internal.vm.compiler.management jdk.jartool jdk.javadoc jdk.jcmd jdk.management.agent jdk.jconsole jdk.jdeps jdk.jdwp.agent jdk.jdi jdk.jfr jdk.jlink jdk.jshell jdk.jsobject jdk.jstatd jdk.localedata jdk.management.jfr jdk.naming.dns jdk.naming.rmi jdk.net jdk.pack jdk.rmic jdk.scripting.nashorn jdk.scripting.nashorn.shell jdk.sctp jdk.security.auth jdk.security.jgss jdk.unsupported.desktop jdk.xml.dom jdk.zipfs"
OS_ARCH="x86_64"
OS_NAME="Windows"
SOURCE=""

and for the same from Oracle

IMPLEMENTOR="Oracle Corporation"
IMPLEMENTOR_VERSION="18.9"
JAVA_VERSION="11.0.2"
JAVA_VERSION_DATE="2019-01-15"
MODULES="java.base java.compiler java.datatransfer java.xml java.prefs java.desktop java.instrument java.logging java.management java.security.sasl java.naming java.rmi java.management.rmi java.net.http java.scripting java.security.jgss java.transaction.xa java.sql java.sql.rowset java.xml.crypto java.se java.smartcardio jdk.accessibility jdk.internal.vm.ci jdk.management jdk.unsupported jdk.internal.vm.compiler jdk.aot jdk.internal.jvmstat jdk.attach jdk.charsets jdk.compiler jdk.crypto.ec jdk.crypto.cryptoki jdk.crypto.mscapi jdk.dynalink jdk.internal.ed jdk.editpad jdk.hotspot.agent jdk.httpserver jdk.internal.le jdk.internal.opt jdk.internal.vm.compiler.management jdk.jartool jdk.javadoc jdk.jcmd jdk.management.agent jdk.jconsole jdk.jdeps jdk.jdwp.agent jdk.jdi jdk.jfr jdk.jlink jdk.jshell jdk.jsobject jdk.jstatd jdk.localedata jdk.management.jfr jdk.naming.dns jdk.naming.rmi jdk.net jdk.pack jdk.rmic jdk.scripting.nashorn jdk.scripting.nashorn.shell jdk.sctp jdk.security.auth jdk.security.jgss jdk.unsupported.desktop jdk.xml.dom jdk.zipfs"
OS_ARCH="x86_64"
OS_NAME="Windows"
SOURCE=".:144d476b6efe"

I see the Oracle version has a source code SHA. If you are buildign binaries form source, then source needs to be identifiable.

bug

All 8 comments

I am also interested in this info for uniquely defining a build (with the SHAs of repos being pulled in to create the binary) in order to relate test results to a particular binary.

Hi, I just downloaded and ran 11.0.4+11 and the release file now has a git sha in it :-)

The source tree for that sha is https://github.com/AdoptOpenJDK/openjdk-jdk11u/tree/381c817fa41d549420b1f3a173d9147aa7a679cd

Is there a way to see the link between that and the source on openjdk.java.net?

The tag there is 6a4d57474e1c971cccf4165b3d9d023928510010 and that occurs in openjdk-jdk11u/.hgtags

IMPLEMENTOR="AdoptOpenJDK" IMPLEMENTOR_VERSION="AdoptOpenJDK" JAVA_VERSION="11.0.4" JAVA_VERSION_DATE="2019-07-16" MODULES="java.base java.compiler java.datatransfer java.xml java.prefs java.desktop java.instrument java.logging java.management java.security.sasl java.naming java.rmi java.management.rmi java.net.http java.scripting java.security.jgss java.transaction.xa java.sql java.sql.rowset java.xml.crypto java.se java.smartcardio jdk.accessibility jdk.internal.vm.ci jdk.management jdk.unsupported jdk.internal.vm.compiler jdk.aot jdk.internal.jvmstat jdk.attach jdk.charsets jdk.compiler jdk.crypto.ec jdk.crypto.cryptoki jdk.crypto.mscapi jdk.dynalink jdk.internal.ed jdk.editpad jdk.hotspot.agent jdk.httpserver jdk.internal.le jdk.internal.opt jdk.internal.vm.compiler.management jdk.jartool jdk.javadoc jdk.jcmd jdk.management.agent jdk.jconsole jdk.jdeps jdk.jdwp.agent jdk.jdi jdk.jfr jdk.jlink jdk.jshell jdk.jsobject jdk.jstatd jdk.localedata jdk.management.jfr jdk.naming.dns jdk.naming.rmi jdk.net jdk.pack jdk.rmic jdk.scripting.nashorn jdk.scripting.nashorn.shell jdk.sctp jdk.security.auth jdk.security.jgss jdk.unsupported.desktop jdk.xml.dom jdk.zipfs" OS_ARCH="x86_64" OS_NAME="Windows" SOURCE=".:git:381c817fa41d"

You can compare against the 11.0.4+11 tag in mercurial (which will have a commit hash) - we don't have a direct mapping yet (since our git source does technically deviate)

I am also interested in this info for uniquely defining a build (with the SHAs of repos being pulled in to create the binary) in order to relate test results to a particular binary.

@smlambert Regarding this, https://github.com/AdoptOpenJDK/openjdk-build/pull/1949 has gone in recently that adds either a git hash or git tag to the scmref field in our metadata. Is that what you're looking for?

As for the original issue, we have long since moved past 11.0.2 (we're now on 11.0.7), can this be closed as the new binaries do have a source hash?

Great, so if I understand correctly, the contents of SOURCE should be the SHA of the AdoptOpenJDK git mirrors (https://github.com/AdoptOpenJDK/openjdk-jdk11u, etc) for hotspot, is it now present for all versions? 8 and 11+? for all impls (though I technically can just look at java -version output for SHAs for openj9, being able to use same approach to query for both is good).

Looking at two recent nightlies for JDK8 and 11, I can confirm JDK8 doesn't contain a source value (JDK11 does however). 8 contains noticeably less data too:

JAVA_VERSION="1.8.0_262"
OS_NAME="Darwin"
OS_VERSION="11.2"
OS_ARCH="x86_64"
SOURCE=""
IMPLEMENTOR="AdoptOpenJDK"
IMPLEMENTOR_VERSION="AdoptOpenJDK"
JAVA_VERSION="11.0.8"
JAVA_VERSION_DATE="2020-07-14"
MODULES="java.base java.compiler java.datatransfer java.xml java.prefs java.desktop java.instrument java.logging java.management java.security.sasl java.naming java.rmi java.management.rmi java.net.http java.scripting java.security.jgss java.transaction.xa java.sql java.sql.rowset java.xml.crypto java.se java.smartcardio jdk.accessibility jdk.internal.vm.ci jdk.management jdk.unsupported jdk.internal.vm.compiler jdk.aot jdk.internal.jvmstat jdk.attach jdk.charsets jdk.compiler jdk.crypto.ec jdk.crypto.cryptoki jdk.dynalink jdk.internal.ed jdk.editpad jdk.hotspot.agent jdk.httpserver jdk.internal.le jdk.internal.opt jdk.internal.vm.compiler.management jdk.jartool jdk.javadoc jdk.jcmd jdk.management.agent jdk.jconsole jdk.jdeps jdk.jdwp.agent jdk.jdi jdk.jfr jdk.jlink jdk.jshell jdk.jsobject jdk.jstatd jdk.localedata jdk.management.jfr jdk.naming.dns jdk.naming.rmi jdk.net jdk.pack jdk.rmic jdk.scripting.nashorn jdk.scripting.nashorn.shell jdk.sctp jdk.security.auth jdk.security.jgss jdk.unsupported.desktop jdk.xml.dom jdk.zipfs"
OS_ARCH="x86_64"
OS_NAME="Darwin"
SOURCE=".:git:824f8474f533"

ok, I guess for jdk8 the story may be slightly more complicated... it will be nice to have it for that LTS version also, but it is fine to do that under another issue, if you wish to close this one, which originally requested it for jdk11

Closing this and following up JDK8 in https://github.com/AdoptOpenJDK/openjdk-build/issues/1966

Was this page helpful?
0 / 5 - 0 ratings