On AIX 7.2, arguments set using the JDK_JAVA_OPTIONS environment variable are picked up twice

[frankikan]

Summary

On AIX, when you specify jvm arguments using the JDK_JAVA_OPTIONS environment variable, they are picked up twice when launching the jvm. As a result, if you have specified an argument that may only occur once on the commandline, the jvm fails to launch.

Steps to reproduce

In a terminal, on an AIX system, execute the following :
export JDK_JAVA_OPTIONS="--patch-module java.base=dummy.jar"
java [Any Class]

Expected results

A JVM is initialized, and the main() method of the class is executed.

Actual results

The JVM doesn't initialize, and these errors are produced :

AdoptOpenJDK Hotspot :
NOTE: Picked up JDK_JAVA_OPTIONS: --patch-module java.base=dummy.jar
NOTE: Picked up JDK_JAVA_OPTIONS: --patch-module java.base=dummy.jar
Error occurred during initialization of VM
Cannot specify java.base more than once to --patch-module

AdoptOpenJDK OpenJ9 :
NOTE: Picked up JDK_JAVA_OPTIONS: --patch-module java.base=dummy.jar
NOTE: Picked up JDK_JAVA_OPTIONS: --patch-module java.base=dummy.jar
Exception in thread "main" java/lang/ExceptionInInitializerError
at java/lang/J9VMInternals.ensureError (java.base@9/J9VMInternals.java:184)
at java/lang/J9VMInternals.recordInitializationFailure (java.base@9/J9VMInternals.java:173)
at java/lang/ClassLoader.initializeClassLoaders (java.base@9/ClassLoader.java:210)
at java/lang/Thread.initialize (java.base@9/Thread.java:430)
at java/lang/Thread. (java.base@9/Thread.java:155)
java/lang/RuntimeException: java.base specified more than once to --patch-module
at jdk/internal/module/ModuleBootstrap.fail (java.base@9/ModuleBootstrap.java:941)
at jdk/internal/module/ModuleBootstrap.decode (java.base@9/ModuleBootstrap.java:881)
at jdk/internal/module/ModuleBootstrap.initModulePatcher (java.base@9/ModuleBootstrap.java:572)
at jdk/internal/module/ModuleBootstrap. (java.base@9/ModuleBootstrap.java:100)
at java/lang/ClassLoader.initializeClassLoaders (java.base@9/ClassLoader.java:210)
at java/lang/Thread.initialize (java.base@9/Thread.java:430)
at java/lang/Thread. (java.base@9/Thread.java:155)

IBM Java :
NOTE: Picked up JDK_JAVA_OPTIONS: --patch-module java.base=dummy.jar
NOTE: Picked up JDK_JAVA_OPTIONS: --patch-module java.base=dummy.jar
Exception in thread "main" java/lang/ExceptionInInitializerError
at java/lang/J9VMInternals.ensureError (java.base@9/J9VMInternals.java:185)
at java/lang/J9VMInternals.recordInitializationFailure (java.base@9/J9VMInternals.java:174)
at java/lang/ClassLoader.initializeClassLoaders (java.base@9/ClassLoader.java:211)
at java/lang/Thread.initialize (java.base@9/Thread.java:430)
at java/lang/Thread. (java.base@9/Thread.java:155)
java/lang/RuntimeException: java.base specified more than once to --patch-module
at jdk/internal/module/ModuleBootstrap.fail (java.base@9/ModuleBootstrap.java:941)
at jdk/internal/module/ModuleBootstrap.decode (java.base@9/ModuleBootstrap.java:881)
at jdk/internal/module/ModuleBootstrap.initModulePatcher (java.base@9/ModuleBootstrap.java:572)
at jdk/internal/module/ModuleBootstrap. (java.base@9/ModuleBootstrap.java:100)
at java/lang/ClassLoader.initializeClassLoaders (java.base@9/ClassLoader.java:211)
at java/lang/Thread.initialize (java.base@9/Thread.java:430)
at java/lang/Thread. (java.base@9/Thread.java:155)

Triaging info

Tested with these Java versions :

AdoptOpenJDK HotSpot :
openjdk version "11.0.11" 2021-04-20
OpenJDK Runtime Environment AdoptOpenJDK-11.0.11+9 (build 11.0.11+9)
OpenJDK 64-Bit Server VM AdoptOpenJDK-11.0.11+9 (build 11.0.11+9, mixed mode)

AdoptOpenJDK OpenJ9 :
openjdk version "11.0.11" 2021-04-20
OpenJDK Runtime Environment AdoptOpenJDK-11.0.11+9 (build 11.0.11+9)
Eclipse OpenJ9 VM AdoptOpenJDK-11.0.11+9 (build openj9-0.26.0, JRE 11 AIX ppc64-64-Bit Compressed References 20210421_970 (JIT enabled, AOT enabled)
OpenJ9 - b4cc246d9
OMR - 162e6f729
JCL - 7796c80419 based on jdk-11.0.11+9)

IBM Java :
java version "11.0.10" 2021-01-19
Java(TM) SE Runtime Environment 11.0.10.0-IBM (build 11.0.10+9)
Eclipse OpenJ9 VM 11.0.10.0-IBM (build openj9-0.24.0, JRE 11 AIX ppc64-64-Bit Compressed References 20210202_3 (JIT enabled, AOT enabled)
OpenJ9 - 345e1b09e2a
OMR - 741e94ea867
JCL - 80f3ace9274 based on jdk-11.0.10+9)

What is your operating system and platform?
AIX 7.2 7200-03-02-1846
AIX Kernel Version : 7.2.3.16 TL03

How did you install Java?
The AdoptOpenJDK versions were extracted from a tar.gz
The IBM jvm was an executable .bin file (ibm-java-jdk_ppc64_aix_11.0.10.0.bin)

Did it work before?
It works when you set the options directly on the commandline, not using the JDK_JAVA_OPTIONS environment variable

Did you test with other Java versions?
I did not find any other AIX compatible jvm besides the ones from AdoptOpenJDK or IBM. I didn't test with other Java 11 or lower versions.

[BrijeshNekkare]

I could reproduce this issue as follows on AIX:

1. export JDK_JAVA_OPTIONS="--patch-module java.base=dummy.jar"
2. java -version

Sequence of events is as follows

1. "main method" gets called with 2 arguments in “java” and “-version".
2. Control eventually hits “CreateExecutionEnvironment method” wherein test for environment variable in “RequiresSetenv method” always returns JNI_TRUE for AIX platform.
3. As a result execve(newexec, argv, newenvp); gets triggered which consequently initiates call to “main method” again.
4. However in this new invocation of main it gets called in with 4 arguments in “java”, “-patch-module” “java.base=dummy.jar” “-version” - 2 original and 2 from JDK_JAVA_OPTIONS environment variable.
5. New trigger of “main” method again parses the JDK_JAVA_OPTIONS environment variable, which by now is already part of java command line arguments.
6. Hence JDK_JAVA_OPTIONS gets parsed twice, leading to fatal error as the JVM directive is related to patch-module.

[BrijeshNekkare]

>dump -X64 -H OpenJDK11U-jre_ppc64_aix_hotspot_11.0.8_10.tar.gz_unpack/jdk-11.0.8+10-jre/bin/java
                        ***Import File Strings***
INDEX  PATH                          BASE                MEMBER              
0      /opt/IBM/xlc/13.1.3/../../../../usr/lpp/xlC/lib:/opt/IBM/xlC/13.1.3/lib/aix61:/opt/IBM/xlC/13.1.3/lib:/opt/IBM/xlc/13.1.3/lib/aix61:/opt/IBM/xlc/13.1.3/lib:/usr/vac/lib/aix53:/usr/lib:/lib      

Index 0 contains the list of directories that are searched for shared objects if LIBPATH is not specified - as seen above it doesn’t contain the path to java specific shared objects. This looks to be the reason why LIBPATH is being set in the Java launcher explicitly. For the LIBPATH environment variable to now take affect, re-exec of the current executable is necessary.

In Summary:

1. During the invocation of Java launcher first time around, JDK_JAVA_OPTIONS (=--patch-module java.base=dummy.jar) is being parsed and added to “java command line parameters”
2. As seen above in dump output, Java launcher doesn’t contain the path to java specific shared objects - which is needed to load the right shared libraries for JRE.
3. Hence LIBPATH is being set in Java launcher and re-exec of the current executable is performed.
4. However this time around JDK_JAVA_OPTIONS is already part of “java command line parameters” and then again it parses the JDK_JAVA_OPTIONS second time around when re-execed
5. So now JDK_JAVA_OPTIONS is being set twice - key being, option set is related to --patch-module
6. JRE bails out now, since step 5 has a potential to create duplicate classes in java.base which is not allowed as per modularity rules.

[BrijeshNekkare]

Its a JDK bug

[ChristianCiach]

I see the same issue with eclipse-temurin:17-alpine on x86-64.

As a workaround, depending on context, you can use JAVA_TOOL_OPTIONS until this is fixed.

[github-actions]

We are marking this issue as stale because it has not been updated for a while. This is just a way to keep the support issues queue manageable.
It will be closed soon unless the stale label is removed by a committer, or a new comment is made.

[github-actions]

We are marking this issue as stale because it has not been updated for a while. This is just a way to keep the support issues queue manageable.
It will be closed soon unless the stale label is removed by a committer, or a new comment is made.

[github-actions]

We are marking this issue as stale because it has not been updated for a while. This is just a way to keep the support issues queue manageable.
It will be closed soon unless the stale label is removed by a committer, or a new comment is made.

[karianna]

@BrijeshNekkare Are you able to report this to JBS?

[Thaodan]

@BrijeshNekkare Are you able to report this to JBS?

I tried to look through the openjdk bug tracker about this and related issues.
It does seem to be bug from what I read:
https://bugs.openjdk.org/browse/JDK-8039152?focusedId=13493041&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-13493041