Re: Proposed fix: buildscript java version detection fails on Linux/Ubuntu on Picked up JAVA_TOOL_OPTIONS
The gradle build tries to find the version of the used Java JDK by running
'java -version', skipping the first line and expects to find the version in
the second line.
However, on Linux (Ubuntu) the first line of *any* Java invocation is Picked
up JAVA_TOOL_OPTIONS: -javaagent:/usr/share/java/jayatanaag.jar[1], thus
failing at detection of the version, aborting the build.
The 'Pickup up...' line is a standard feature of the JDK and a legacy that
doesn't seem to be removed soon[2].
I guess the build script needs to accommodate for this.
Proposed fix:
// Determine the verion of Java in JDK_HOME. It looks like this:
//
// $ java -version
// Picked up JAVA_TOOL_OPTIONS: -javaagent:/usr/share/java/jayatanaag.jar
// java version 1.7.0_45
// Java(TM) SE Runtime Environment (build 1.7.0_45-b18)
// Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode)
//
// The first line is optional, we need to parse the third line
def inStream = new java.io.BufferedReader(new java.io.InputStreamReader(new
java.lang.ProcessBuilder(JAVA, -version).start().getErrorStream()));
try {
String v = inStream.readLine();
if (v != null) {
if (v.startsWith(Picked up)) {
inStream.readLine();
}
v = inStream.readLine();
Why not just use java -fullversion instead?
$ java -fullversion
java full version 1.8.0_60-ea-b14
$ JAVA_TOOL_OPTIONS=-Xmx512M java -fullversion
java full version 1.8.0_60-ea-b14
$ java -version
java version 1.8.0_60-ea
Java(TM) SE Runtime Environment (build 1.8.0_60-ea-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.60-b14, mixed mode)
$ JAVA_TOOL_OPTIONS=-Xmx512M java -version
Picked up JAVA_TOOL_OPTIONS: -Xmx512M
java version 1.8.0_60-ea
Java(TM) SE Runtime Environment (build 1.8.0_60-ea-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.60-b14, mixed mode)
It's a lot less stuff to parse. Also, java -fullversion does not start the
VM, so should be faster.
-DrD-
Proposed fix: buildscript java version detection fails on Linux/Ubuntu on Picked up JAVA_TOOL_OPTIONS
The gradle build tries to find the version of the used Java JDK by
running 'java -version', skipping the first line and expects to find the
version in the second line.
However, on Linux (Ubuntu) the first line of *any* Java invocation is
Picked up JAVA_TOOL_OPTIONS:
-javaagent:/usr/share/java/jayatanaag.jar[1], thus failing at detection
of the version, aborting the build.
The 'Pickup up...' line is a standard feature of the JDK and a legacy
that doesn't seem to be removed soon[2].
I guess the build script needs to accommodate for this.
Proposed fix:
// Determine the verion of Java in JDK_HOME. It looks like this:
//
// $ java -version
// Picked up JAVA_TOOL_OPTIONS:
-javaagent:/usr/share/java/jayatanaag.jar
// java version 1.7.0_45
// Java(TM) SE Runtime Environment (build 1.7.0_45-b18)
// Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode)
//
// The first line is optional, we need to parse the third line
def inStream = new java.io.BufferedReader(new
java.io.InputStreamReader(new java.lang.ProcessBuilder(JAVA,
-version).start().getErrorStream()));
try {
String v = inStream.readLine();
if (v != null) {
if (v.startsWith(Picked up)) {
inStream.readLine();
}
v = inStream.readLine();
[1] https://community.oracle.com/thread/1239778?start=0tstart=0
[2] https://bugs.openjdk.java.net/browse/JDK-8039152
Re: Proposed fix: buildscript java version detection fails on Linux/Ubuntu on Picked up JAVA_TOOL_OPTIONS
David DeHaven wrote:
The gradle build tries to find the version of the used Java JDK by running
'java -version', skipping the first line and expects to find the version in the
second line.
However, on Linux (Ubuntu) the first line of *any* Java invocation is Picked up
JAVA_TOOL_OPTIONS: -javaagent:/usr/share/java/jayatanaag.jar[1], thus failing at
detection of the version, aborting the build.
The 'Pickup up...' line is a standard feature of the JDK and a legacy that
doesn't seem to be removed soon[2].
I guess the build script needs to accommodate for this.
Proposed fix:
// Determine the verion of Java in JDK_HOME. It looks like this:
//
// $ java -version
// Picked up JAVA_TOOL_OPTIONS: -javaagent:/usr/share/java/jayatanaag.jar
// java version 1.7.0_45
// Java(TM) SE Runtime Environment (build 1.7.0_45-b18)
// Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode)
//
// The first line is optional, we need to parse the third line
def inStream = new java.io.BufferedReader(new java.io.InputStreamReader(new
java.lang.ProcessBuilder(JAVA, -version).start().getErrorStream()));
try {
String v = inStream.readLine();
if (v != null) {
if (v.startsWith(Picked up)) {
inStream.readLine();
}
v = inStream.readLine();
Why not just use java -fullversion instead?
$ java -fullversion
java full version 1.8.0_60-ea-b14
$ JAVA_TOOL_OPTIONS=-Xmx512M java -fullversion
java full version 1.8.0_60-ea-b14
$ java -version
java version 1.8.0_60-ea
Java(TM) SE Runtime Environment (build 1.8.0_60-ea-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.60-b14, mixed mode)
$ JAVA_TOOL_OPTIONS=-Xmx512M java -version
Picked up JAVA_TOOL_OPTIONS: -Xmx512M
java version 1.8.0_60-ea
Java(TM) SE Runtime Environment (build 1.8.0_60-ea-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.60-b14, mixed mode)
It's a lot less stuff to parse. Also, java -fullversion does not start the
VM, so should be faster.
That makes sense as long as the output has everything we need. I need to
make changes in this area anyway for JDK 9 in support of the new version
string (JEP 223). See:
https://bugs.openjdk.java.net/browse/JDK-8133750
So this would seems like another good change to do, either as part of
that fix or separately.
-- Kevin
-DrD-
Re: Proposed fix: buildscript java version detection fails on Linux/Ubuntu on Picked up JAVA_TOOL_OPTIONS
I can't comment on non-Oracle JDKs, but It's in libjli so anything based on
OpenJDK should support it.
-DrD-
I was not aware of the existence of the -fullversion option. It is not listed
at the Oracle site, afaik. Can it be assumed to be present in non-OpenJDK,
non-Oracle JDKs?
David DeHaven schreef op 2015-08-26 15:38:
The gradle build tries to find the version of the used Java JDK by running
'java -version', skipping the first line and expects to find the version in
the second line.
However, on Linux (Ubuntu) the first line of *any* Java invocation is
Picked up JAVA_TOOL_OPTIONS:
-javaagent:/usr/share/java/jayatanaag.jar[1], thus failing at detection of
the version, aborting the build.
The 'Pickup up...' line is a standard feature of the JDK and a legacy that
doesn't seem to be removed soon[2].
I guess the build script needs to accommodate for this.
Proposed fix:
// Determine the verion of Java in JDK_HOME. It looks like this:
//
// $ java -version
// Picked up JAVA_TOOL_OPTIONS: -javaagent:/usr/share/java/jayatanaag.jar
// java version 1.7.0_45
// Java(TM) SE Runtime Environment (build 1.7.0_45-b18)
// Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode)
//
// The first line is optional, we need to parse the third line
def inStream = new java.io.BufferedReader(new java.io.InputStreamReader(new
java.lang.ProcessBuilder(JAVA, -version).start().getErrorStream()));
try {
String v = inStream.readLine();
if (v != null) {
if (v.startsWith(Picked up)) {
inStream.readLine();
}
v = inStream.readLine();
Why not just use java -fullversion instead?
$ java -fullversion
java full version 1.8.0_60-ea-b14
$ JAVA_TOOL_OPTIONS=-Xmx512M java -fullversion
java full version 1.8.0_60-ea-b14
$ java -version
java version 1.8.0_60-ea
Java(TM) SE Runtime Environment (build 1.8.0_60-ea-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.60-b14, mixed mode)
$ JAVA_TOOL_OPTIONS=-Xmx512M java -version
Picked up JAVA_TOOL_OPTIONS: -Xmx512M
java version 1.8.0_60-ea
Java(TM) SE Runtime Environment (build 1.8.0_60-ea-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.60-b14, mixed mode)
It's a lot less stuff to parse. Also, java -fullversion does not
start the VM, so should be faster.
-DrD-
Re: Proposed fix: buildscript java version detection fails on Linux/Ubuntu on Picked up JAVA_TOOL_OPTIONS
I was not aware of the existence of the -fullversion option. It is not
listed at the Oracle site, afaik. Can it be assumed to be present in
non-OpenJDK, non-Oracle JDKs?
David DeHaven schreef op 2015-08-26 15:38:
The gradle build tries to find the version of the used Java JDK by
running 'java -version', skipping the first line and expects to find
the version in the second line.
However, on Linux (Ubuntu) the first line of *any* Java invocation is
Picked up JAVA_TOOL_OPTIONS:
-javaagent:/usr/share/java/jayatanaag.jar[1], thus failing at
detection of the version, aborting the build.
The 'Pickup up...' line is a standard feature of the JDK and a legacy
that doesn't seem to be removed soon[2].
I guess the build script needs to accommodate for this.
Proposed fix:
// Determine the verion of Java in JDK_HOME. It looks like this:
//
// $ java -version
// Picked up JAVA_TOOL_OPTIONS:
-javaagent:/usr/share/java/jayatanaag.jar
// java version 1.7.0_45
// Java(TM) SE Runtime Environment (build 1.7.0_45-b18)
// Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode)
//
// The first line is optional, we need to parse the third line
def inStream = new java.io.BufferedReader(new
java.io.InputStreamReader(new java.lang.ProcessBuilder(JAVA,
-version).start().getErrorStream()));
try {
String v = inStream.readLine();
if (v != null) {
if (v.startsWith(Picked up)) {
inStream.readLine();
}
v = inStream.readLine();
Why not just use java -fullversion instead?
$ java -fullversion
java full version 1.8.0_60-ea-b14
$ JAVA_TOOL_OPTIONS=-Xmx512M java -fullversion
java full version 1.8.0_60-ea-b14
$ java -version
java version 1.8.0_60-ea
Java(TM) SE Runtime Environment (build 1.8.0_60-ea-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.60-b14, mixed mode)
$ JAVA_TOOL_OPTIONS=-Xmx512M java -version
Picked up JAVA_TOOL_OPTIONS: -Xmx512M
java version 1.8.0_60-ea
Java(TM) SE Runtime Environment (build 1.8.0_60-ea-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.60-b14, mixed mode)
It's a lot less stuff to parse. Also, java -fullversion does not
start the VM, so should be faster.
-DrD-
Re: Proposed fix: buildscript java version detection fails on Linux/Ubuntu on Picked up JAVA_TOOL_OPTIONS
I will also note that OpenJFX depends on OpenJDK, so I am fine using
-fullversion as long as it works in both OpenJDK and Oracle JDK
builds, and both before and after the version string changes in JEP-223.
-- Kevin
David DeHaven wrote:
I can't comment on non-Oracle JDKs, but It's in libjli so anything based on
OpenJDK should support it.
-DrD-
I was not aware of the existence of the -fullversion option. It is not listed
at the Oracle site, afaik. Can it be assumed to be present in non-OpenJDK,
non-Oracle JDKs?
David DeHaven schreef op 2015-08-26 15:38:
The gradle build tries to find the version of the used Java JDK by running
'java -version', skipping the first line and expects to find the version in the
second line.
However, on Linux (Ubuntu) the first line of *any* Java invocation is Picked up
JAVA_TOOL_OPTIONS: -javaagent:/usr/share/java/jayatanaag.jar[1], thus failing at
detection of the version, aborting the build.
The 'Pickup up...' line is a standard feature of the JDK and a legacy that
doesn't seem to be removed soon[2].
I guess the build script needs to accommodate for this.
Proposed fix:
// Determine the verion of Java in JDK_HOME. It looks like this:
//
// $ java -version
// Picked up JAVA_TOOL_OPTIONS: -javaagent:/usr/share/java/jayatanaag.jar
// java version 1.7.0_45
// Java(TM) SE Runtime Environment (build 1.7.0_45-b18)
// Java HotSpot(TM) 64-Bit Server VM (build 24.45-b08, mixed mode)
//
// The first line is optional, we need to parse the third line
def inStream = new java.io.BufferedReader(new java.io.InputStreamReader(new
java.lang.ProcessBuilder(JAVA, -version).start().getErrorStream()));
try {
String v = inStream.readLine();
if (v != null) {
if (v.startsWith(Picked up)) {
inStream.readLine();
}
v = inStream.readLine();
Why not just use java -fullversion instead?
$ java -fullversion
java full version 1.8.0_60-ea-b14
$ JAVA_TOOL_OPTIONS=-Xmx512M java -fullversion
java full version 1.8.0_60-ea-b14
$ java -version
java version 1.8.0_60-ea
Java(TM) SE Runtime Environment (build 1.8.0_60-ea-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.60-b14, mixed mode)
$ JAVA_TOOL_OPTIONS=-Xmx512M java -version
Picked up JAVA_TOOL_OPTIONS: -Xmx512M
java version 1.8.0_60-ea
Java(TM) SE Runtime Environment (build 1.8.0_60-ea-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.60-b14, mixed mode)
It's a lot less stuff to parse. Also, java -fullversion does not
start the VM, so should be faster.
-DrD-
