How to suppress verbosity when settting _JAVA_OPTIONS?

[Magnus Ihse Bursie]

On 2017-09-04 13:18, John Paul Adrian Glaubitz wrote:
> Hello!
>
> I'm currently testing Zero builds on Linux Alpha, in my particular 
> case on
> QEMU in a Debian unstable alpha chroot, using OpenJDK 8 for 
> bootstrapping.
>
> For some reason, OpenJDK 8 from Debian's openjdk8 assumes a heap size 
> which
> is too small and refuses to start:
>
> (sid-alpha-sbuild)root at nofan:/# java -version
> Error occurred during initialization of VM
> Too small initial heap
> (sid-alpha-sbuild)root at nofan:/#
>
> This can be fixed by overriding the heap settings with _JAVA_OPTIONS:
>
> (sid-alpha-sbuild)root at nofan:/# export _JAVA_OPTIONS="-Xmx1024m -Xms256m"
> (sid-alpha-sbuild)root at nofan:/# java -version
> Picked up _JAVA_OPTIONS: -Xmx1024m -Xms256m
> openjdk version "1.8.0_141"
> OpenJDK Runtime Environment (build 1.8.0_141-8u141-b15-3-b15)
> OpenJDK 64-Bit Zero VM (build 25.141-b15, interpreted mode)
> (sid-alpha-sbuild)root at nofan:/#
>
> As you can see, this has the side effect that the JVM becomes very
> chatty about the fact that _JAVA_OPTIONS were set.
>
> While this doesn't seem to be a problem at first sight, it becomes
> a problem when trying to run configure for JDK10 which will fail
> because of the unexpected output when trying to determine the version
> of the boot JDK:
>
> configure: Found potential Boot JDK using configure arguments
> configure: Potential Boot JDK found at 
> /usr/lib/jvm/java-8-openjdk-alpha/ is incorrect JDK version (Picked up 
> _JAVA_OPTIONS: -Xmx1024m -Xms256m); ignoring
> configure: (Your Boot JDK must be version 8 or 9)
> configure: error: The path given by --with-boot-jdk does not contain a 
> valid Boot JDK
> configure exiting with result code 1
>
> Is there any way to silence the JVM regarding "_JAVA_OPTIONS"? If no,
> we should probably patch the JVM to do that by default.
Ouch! Lots of small, idiotic issues.

For the build identification part: are both the _JAVA_OPTIONS and the 
version outputted to stdout? Or can you separate them by separating 
stdout/stderr?

Otherwise, this patch would solve the issue in your case. I'm not sure 
how it would affect all other java instances we try to detect, so I'm a 
bit reluctant to take it in.

diff --git a/common/autoconf/boot-jdk.m4 b/common/autoconf/boot-jdk.m4
--- a/common/autoconf/boot-jdk.m4
+++ b/common/autoconf/boot-jdk.m4
@@ -74,7 +74,7 @@
            BOOT_JDK_FOUND=no
          else
            # Oh, this is looking good! We probably have found a proper 
JDK. Is it the correct version?
-          BOOT_JDK_VERSION=`"$BOOT_JDK/bin/java" -version 2>&1 | $HEAD 
-n 1`
+          BOOT_JDK_VERSION=`"$BOOT_JDK/bin/java" -version 2>&1 | $GREP 
version | $HEAD -n 1`

            # Extra M4 quote needed to protect [] in grep expression.
            [FOUND_CORRECT_VERSION=`$ECHO $BOOT_JDK_VERSION | $EGREP 
'\"9([\.+-].*)?\"|(1\.[89]\.)'`]

But the main problem here seems to be the Debian openjdk8 instance that 
crashes on "java -version". Seems like a good and simple test to add to 
your test matrix. ;-)

/Magnus

>
> Adrian
>