IcedTeaWeb: using java 9 run args ?
Laurent Bourgès
bourges.laurent at gmail.com
Wed Jan 23 07:52:33 UTC 2019
Hi Jiri,
I am still fixing windows script bugs on my github run-args branch...
I have many questions, let's talk later.
Laurent
Le lun. 21 janv. 2019 à 23:09, Laurent Bourgès <bourges.laurent at gmail.com>
a écrit :
> 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/20190123/e04cbb30/attachment-0001.html>
More information about the distro-pkg-dev
mailing list