IcedTeaWeb: using java 9 run args ?
Laurent Bourgès
bourges.laurent at gmail.com
Thu Jan 17 15:23:26 UTC 2019
Hi Jiri,
That's good questions, some answers below:
Le jeu. 17 janv. 2019 à 11:21, Jiri Vanek <jvanek at redhat.com> a écrit :
> Hi Laurent!
>
> I'm moving to stage when I will be implementing those args for native
> launchers.
> In meantime, there appeared twomore cases.
> - People wish to add items to (boot)classapths - mostly this is about
> custom build of FX
> - People wish to remove items fro (boot)classapths - I noted application
> with custom build of rhino.
>
Moreover, to adopt OpenJFX11, it requires to hack the module path (or use
an alternate run.args), on my machine I have:
/openjfx/jfx-dev/build$ cat run.args
--module-path="/home/graphics-rasterizer/openjfx/jfx-dev/build/sdk/lib"
--add-modules=javafx.base,javafx.controls,javafx.fxml,javafx.graphics,javafx.media,javafx.swing,javafx.web
I wonder if hacking ITW's run.args would be allowed too ?
More generally, I wonder if how much launchers should be customized at
runtime using environment variables ? or rely on install / customization
scripts to adapt ITW to runtime environments ?
> With shell launchers, one can do this on his own. No meter of complexity.
> In native lunchers, this
> is impossible without recompilation.
>
FYI, I have new failure building native launchers today:
---- tests_main::compose_arguments_test stdout ----
thread 'tests_main::compose_arguments_test' panicked at 'Error obtaining
file name form hardcoded jar', libcore/option.rs:1000:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a
verbose backtrace.
stack backtrace:
0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
1: std::sys_common::backtrace::print
2: std::panicking::default_hook::{{closure}}
3: std::panicking::default_hook
4: std::panicking::rust_panic_with_hook
5: std::panicking::continue_panic_fmt
6: rust_begin_unwind
7: core::panicking::panic_fmt
8: core::option::expect_failed
9: <core::option::Option<T>>::expect
at libcore/option.rs:312
10: launcher::jars_helper::resolve_jar
at src/jars_helper.rs:45
11: launcher::jars_helper::append_if_exists
at src/jars_helper.rs:108
12: launcher::jars_helper::get_bootcp_members
at src/jars_helper.rs:118
13: launcher::jars_helper::get_bootclasspath
at src/jars_helper.rs:163
14: launcher::compose_arguments
at src/main.rs:51
15: launcher::tests_main::compose_arguments_test
at src/main.rs:134
16: launcher::tests_main::compose_arguments_test::{{closure}}
at src/main.rs:129
17: core::ops::function::FnOnce::call_once
at libcore/ops/function.rs:238
18: <F as alloc::boxed::FnBox<A>>::call_box
19: __rust_maybe_catch_panic
---- utils::tests_utils::try_jre_dir_java_on_path_but_no_bin stdout ----
thread 'utils::tests_utils::try_jre_dir_java_on_path_but_no_bin' panicked
at 'assertion failed: `(left == right)`
left:
`Some("/home/bourgesl/libs/icedtea-web/tests.build/rust_tests_tmp")`,
right: `Some("/home/icedtea/icedtea-web/tests.build/rust_tests_tmp")`',
src/utils.rs:195:9
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a
verbose backtrace.
stack backtrace:
0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
1: std::sys_common::backtrace::print
2: std::panicking::default_hook::{{closure}}
3: std::panicking::default_hook
4: std::panicking::rust_panic_with_hook
5: std::panicking::continue_panic_fmt
6: std::panicking::begin_panic_fmt
7: launcher::utils::tests_utils::try_jre_dir_java_on_path_but_no_bin
at src/utils.rs:195
8:
launcher::utils::tests_utils::try_jre_dir_java_on_path_but_no_bin::{{closure}}
at src/utils.rs:182
9: core::ops::function::FnOnce::call_once
at libcore/ops/function.rs:238
10: <F as alloc::boxed::FnBox<A>>::call_box
11: __rust_maybe_catch_panic
---- utils::tests_utils::try_jre_exists_on_path stdout ----
thread 'utils::tests_utils::try_jre_exists_on_path' panicked at 'assertion
failed: `(left == right)`
left:
`Some("/home/bourgesl/libs/icedtea-web/tests.build/rust_tests_tmp/itw-1547734002263-36-rusttmp")`,
right:
`Some("/home/icedtea/icedtea-web/tests.build/rust_tests_tmp/itw-1547734002263-36-rusttmp")`',
src/utils.rs:165:9
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a
verbose backtrace.
stack backtrace:
0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
1: std::sys_common::backtrace::print
2: std::panicking::default_hook::{{closure}}
3: std::panicking::default_hook
4: std::panicking::rust_panic_with_hook
5: std::panicking::continue_panic_fmt
6: std::panicking::begin_panic_fmt
7: launcher::utils::tests_utils::try_jre_exists_on_path
at src/utils.rs:165
8: launcher::utils::tests_utils::try_jre_exists_on_path::{{closure}}
at src/utils.rs:156
9: core::ops::function::FnOnce::call_once
at libcore/ops/function.rs:238
10: <F as alloc::boxed::FnBox<A>>::call_box
11: __rust_maybe_catch_panic
failures:
tests_main::compose_arguments_test
utils::tests_utils::try_jre_dir_java_on_path_but_no_bin
utils::tests_utils::try_jre_exists_on_path
test result: FAILED. 52 passed; 3 failed; 0 ignored; 0 measured; 0 filtered
out
> So my current mindset is pointing to the launcher.properties file,
> included in ITW_HOME or (for
> distributions) in some known path.
>
Good, so you propose to have a new launcher.properties file for native
launchers only.
> This should contains fileds like:
> jvm_default_args=xmx...--add-reads...--patch...
> (note that this do not handle)
>
As jdk9+ args (add-reads, add-exports, module ...) are specific to JDK9+, I
would prefer having specific jigsaw variables to deal with them as using
such flags are forbidden on JDK8.
In the former run.args I proposed, I explicitely splitted the static args
and dynamic args:
cat itw-run.args
# -------------------------------------
# IcedTea-Web jigsaw run args (jdk9+)
# -------------------------------------
--add-reads=java.base=ALL-UNNAMED,java.desktop
--add-reads=java.desktop=ALL-UNNAMED,java.naming
--add-reads=java.naming=ALL-UNNAMED,java.desktop
--add-exports=java.desktop/sun.awt=ALL-UNNAMED,java.desktop
--add-exports=java.desktop/javax.jnlp=ALL-UNNAMED,java.desktop
--add-exports=java.base/com.sun.net.ssl.internal.ssl=ALL-UNNAMED,java.desktop
--add-exports=java.base/sun.net.www.protocol.jar=ALL-UNNAMED,java.desktop
--add-exports=java.base/sun.security.action=ALL-UNNAMED,java.desktop
--add-exports=java.base/sun.security.provider=ALL-UNNAMED,java.desktop
--add-exports=java.base/sun.security.util=ALL-UNNAMED,java.desktop
--add-exports=java.base/sun.security.validator=ALL-UNNAMED,java.desktop
--add-exports=java.base/sun.security.x509=ALL-UNNAMED,java.desktop
--add-exports=java.base/jdk.internal.util.jar=ALL-UNNAMED,java.desktop
--add-exports=java.base/sun.net.www.protocol.http=ALL-UNNAMED,java.desktop
--add-exports=java.desktop/sun.awt.X11=ALL-UNNAMED,java.desktop
--add-exports=java.desktop/sun.applet=ALL-UNNAMED,java.desktop
--add-exports=java.desktop/sun.applet=ALL-UNNAMED,jdk.jsobject
--add-exports=java.naming/com.sun.jndi.toolkit.url=ALL-UNNAMED,java.desktop
I left dynamic args in the script:
*ITW_INS=/home/bourgesl/libs/icedtea-web-1.7-HEAD/installITW_SHARE=$ITW_INS/share*
if [ "x$MODULAR_JDK" == "xYES" ] ; then
COMMAND[k]="--patch-module"
k=$((k+1))
COMMAND[k]="java.desktop=$ITW_SHARE/icedtea-web/netx.jar"
k=$((k+1))
# jsobject must be patched separately from plugin
# otherwise netscape pkg would be shared by two modules, which is forbiden
# plugin jar may not be built
if [ ! "x$JSOBJECT_JAR" == "x" ] ; then
COMMAND[k]="--patch-module"
k=$((k+1))
COMMAND[k]="jdk.jsobject=$JSOBJECT_JAR"
k=$((k+1))
fi
# add JDK9 arg file:
COMMAND[k]="@$ITW_INS/bin/itw-run.args"
k=$((k+1))
else
COMMAND[k]="-classpath"
k=$((k+1))
COMMAND[k]="${CP}"
k=$((k+1))
fi
I must fix the variable names (ITW_INS, ITW_SHARE) in my old script to use
now ITW_HOME instead ... as I prefer using relative paths and I prefer
having a single sed substitution at the beginning of the script (and use
relative paths) to minimize the number of variables to deal with. (my own
brain is very limited in bash wisardry)
As JDK11 do not support plugin, what is the use case for JSOBJECT_JAR ?
> jvm_bootcp_filter=regexes or items toremove from bootcp
> jvm_cp_filter=regexes or items toremove from cp
> jvm_additional_boot_cp=additional items to be added to bootcp
> jvm_additional_cp=additional items to be added to cp
>
> maybe some fields like:
> jvm_modular_options=-add-reads...-patch... ?
> jsobject_extending_patching=-add-reads...-patch... ?
>
I like the jvm_modular_options approach but I would have named it:
'jvm_jigsaw_args' instead
However, I do not what is jsobject_extending_patching for ? useless or
anyway it can be derived from other paths / variables (itw internal)
> Something else?
>
Sounds good.
I wonder if it is possible to allow customization in run.args files ?
>
> Few questions remains whether to bother with this file to be per-jdk,
> settup-able from commandline
> and so on....
>
> In limited scope, this can be read also from .sh/.bat files (we already
> read custom jvm from here)
>
I agree reading launcher.properties from shell/bat scripts could certainly
help...
Cheers,
Laurent
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20190117/f2827c17/attachment.html>
More information about the distro-pkg-dev
mailing list