IcedTeaWeb: using java 9 run args ?
Jiri Vanek
jvanek at redhat.com
Fri Jan 18 12:29:51 UTC 2019
On 1/17/19 4:23 PM, Laurent Bourgès wrote:
> Hi Jiri,
> That's good questions, some answers below:
>
> Le jeu. 17 janv. 2019 à 11:21, Jiri Vanek <jvanek at redhat.com <mailto: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 ?
Yup. I know. So yes, hacking of all switches should be allowed.
>
> 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 ?
Itw should work out of the box , but should allow as maximised customisation as possible. With shell
luncher you have % freedom. The native ones are losing this. I\m not much happy from it, especially
when I see how people are (mis)using it.
>
>
> 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
hat looks like issue in coode, whre I forget some of the variables may not be substitued during
build. Will fix it (but.. see below)
You may face one more kind of issue, when custom cargo-tests requires you to set ITW_LIBS=BOTH #or
any other of three vlaid vlaues.
So my wrong. Sorry. In meantime, you can workaround it by providing all optional jars, and include
plugin.jar
> 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
...
> 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.
It depends how we all agree. I more propose to have proeprties for 1.8 for boith shell and native,
and simple palintext for 1.7
>
>
> 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.
>
Yes. that is something what have to be reolved/ By one way or another.
In case of properties, I can imageine eg:
modular-switches=....
ehich will be used in jdk 9+, until jdkXY which will be last where --add.../--patch... exists. And
that can be jdk14.
> 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/install
> ITW_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
>
Yup. this make some sense. But I dont like the special treatment. of single jar. (unluckily in this
case I still do not have golden solution)
> 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 ?
Good point.
Even with plugin.jar and javaws --html, jsobject is very likel redundant.
Originally I ownted to remove it 1.9 together with native plugin, but conisdetring the troubles it
is bringing....
>
>
> 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)
Sounds reasonable.
>
>
> Something else?
>
>
> Sounds good.
> I wonder if it is possible to allow customization in run.args files ?
I imagine the run.args files as read-only. The default which always works. But to allow its
customisation/overrides in *regular* deployment.properties.
>
>
>
> 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...
It is easy - untill you hit multi line property:(
So again, depends on our agreement. It can be properties file wihtout multiline support (eg also
rust lunchers now supports only single line) but then the --add.../--patch.. will be extra unreadable...
So brainstorimng still in in progress:)\
I will be on PTO since ...10minutes ahead:) to wednesday (included). I'm also afraid thet my OpenJDK
duties will kill me at thursday and friday :(
I had eyballed a bit your's patch, and I will ask you, if you can split it to two. 1) patch withc
crosscompile .bats 2) which adds args.
My reason is, that I already started to do 1). So i would like to compare the results.
See you again in a week!
J.
>
> Cheers,
> Laurent
--
Jiri Vanek
Senior QE engineer, OpenJDK QE lead, Mgr.
Red Hat Czech
jvanek at redhat.com M: +420775390109
More information about the distro-pkg-dev
mailing list