IcedTeaWeb: using java 9 run args ?
Laurent Bourgès
bourges.laurent at gmail.com
Thu Jan 17 22:49:00 UTC 2019
Hi Jiri,
Here is my first step to adopt run.args (jdk9+) in IcedTeaWeb 1.8.
I modified the Makefile and simplified linux shell script (+ fixed BUNDLED
mode), I will adapt the windows batch script asap.
I did not remove any shell variable but according to me, it would be
simpler to provide ITW_HOME (install path), then only use relative paths
(even hard-coded names).
The linux shell script has so many variables, that is looks very difficult
to read and all these variables should be redefined for the BUNDLE
distribution mode ...
I tested it with OpenJDK8 + OpenJDK11 & 13 on my ubuntu machine with the 2
cases (install dir + bundled)
To use OpenJDK11, I tested 2 solutions:
1. hack the JRE/JAVA variables in the script
2. use ITW control panel to select another ITW JVM (select OpenJDK11
install dir), it works like a charm (CUSTOM_JRE)
PS: If you prefer, I can start another RFC thread.
Cheers,
Laurent
Le jeu. 17 janv. 2019 à 16:23, Laurent Bourgès <bourges.laurent at gmail.com>
a écrit :
> 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/c531f0ca/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch-run-args.diff
Type: text/x-patch
Size: 17945 bytes
Desc: not available
URL: <https://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20190117/c531f0ca/patch-run-args-0001.diff>
More information about the distro-pkg-dev
mailing list