Aleksei,
If I get it right, the fix would not work for the case when there are
`arguments` properties in `ArgOptions` section of a config file.
Why not just check if the parent process is the same executable as the
current one and if this is the case don't read data from the config file
but pass executable arguments as is in JLI_Launch() call?
- Alexey
On 6/24/2020 11:48 AM, Aleksei Voitylov wrote:
Hi,
There are systems that update LD_LIBRARY_PATH or directly return
JNI_TRUE in method RequiresSetenv(const char *jvmpath) from java_md.c
file to request re-execution of the current executable. This leads to
the fact that jpackage application adds some provided arguments twice.
Bug: https://bugs.openjdk.java.net/browse/JDK-8248239
Fix: http://cr.openjdk.java.net/~avoitylov/webrev.8248239.00/
The root cause of the issue is that jpackage application expects one
number of arguments but JLI reexecutes them with another number of
arguments.
For example, a jpackage application can be run with arguments:
./app/bin/app -Dparam2=Param2 B1 B2 B3
it adds arguments from the config file and calls JLI with arguments:
app/bin/app -classpath -Dparam1=Param1 -m com.hello/com.hello.Hello
-Dparam2=Param2 B1 B2 B3
JLI re-executes the app with new arguments so the app adds some
arguments one more time after the re-execution.
./app/bin/app -classpath -Dparam1=Param1 -m
com.hello/com.hello.Hello -classpath -Dparam1=Param1 -m
com.hello/com.hello.Hello -Dparam2=Param2 B1 B2 B3
A step by step example that illustrates the issue:
Run jpackage to create an executable application:
jpackage --dest output --name app --type app-image --module-path
input-modules --module com.hello/com.hello.Hello --arguments "A1 A2 A3"
--verbose --java-options -Dparam1=Param1
Executable application with the app/lib/app/app.cfg config file is created:
---- app.cfg ----
[Application]
app.name=app
app.version=1.0
app.runtime=$ROOTDIR/lib/runtime
app.identifier=com.hello
app.classpath=
app.mainmodule=com.hello/com.hello.Hello
[JavaOptions]
java-options=-Dparam1=Param1
[ArgOptions]
arguments=A1
arguments=A2
arguments=A3
-----------
Run the application:
./output/app/bin/app -Dparam2=Param2 B1 B2 B3
Chain of JDK methods execution:
LinuxLauncher main()
args: 5 [./app/bin/app -Dparam2=Param2 B1 B2 B3 ]
AppLauncher createJvmLauncher()
args: 4 [-Dparam2=Param2 B1 B2 B3 ]
JvmLauncher.cpp Jvm::initFromConfigFile() - adds JavaOptions from app.cfg
args: 10 [app/bin/app -classpath -Dparam1=Param1 -m
com.hello/com.hello.Hello -Dparam2=Param2 B1 B2 B3 ]
AppLauncher Jvm::launch() - JLI re-executes the app
LinuxLauncher main()
args: 10 [app/bin/app -classpath -Dparam1=Param1 -m
com.hello/com.hello.Hello -Dparam2=Param2 B1 B2 B3 ]
AppLauncher createJvmLauncher()
args: 9 [-classpath -Dparam1=Param1 -m com.hello/com.hello.Hello
-Dparam2=Param2 B1 B2 B3 ]
JvmLauncher.cpp Jvm::initFromConfigFile() - adds JavaOptions from app.cfg
args: 15 [./app/bin/app -classpath -Dparam1=Param1 -m
com.hello/com.hello.Hello -classpath -Dparam1=Param1 -m
com.hello/com.hello.Hello -Dparam2=Param2 B1 B2 B3 ]
^^^
Some arguments like "-classpath -Dparam1=Param1 -m
com.hello/com.hello.Hello" are added twice.
Tested with test/jdk/tools/jpackage/share/jdk/jpackage with no
regressions on Linux, Windows, Mac. On systems affected, the tests now pass.
Thanks,
-Aleksei
