IcedTeaWeb: using java 9 run args ?
Laurent Bourgès
bourges.laurent at gmail.com
Mon Jan 21 22:09:55 UTC 2019
Hi Jiri,
I achieved my goal:
I made windows batch script work well either on OpenJDK8 or 11, 12 ea
(tested on win7) : itw 1.8 runs my app on jdk11 / windows !
I pushed my changes on my github mirror (1.8):
https://github.com/bourgesl/icedtea-web/commit/9443490d301516a5101a672ff09e8dff78929b5d
Here is the complete win batch:
https://github.com/bourgesl/icedtea-web/blob/run-args/shell-launcher/launchers.bat.in
PS: I rewrote completely the windows script to mimic linux one: it was
painful with lot of tricky syntax...
One remaining bug: handle properly script args (-J...) to make fork work.
I hope I can do it with some tricky for in (%*) to split args...
Another thing: getting JVM from config file is not handled yet but using
JAVA_HOME or registry works well now.
PS: I will soon propose a complete patch to ITW as another RFC.
PS2: OpenJDK 11.0.2 did not have the SequencedEvent bug fix backport... ��
but 12 works OK.
Cheers,
Laurent
Le ven. 18 janv. 2019 à 13:29, Jiri Vanek <jvanek at redhat.com> a écrit :
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20190121/8643a635/attachment.html>
More information about the distro-pkg-dev
mailing list