IcedTeaWeb: using java 9 run args ?
Laurent Bourgès
bourges.laurent at gmail.com
Fri Jan 25 12:36:38 UTC 2019
Hi Jiri,
I finally finished rewriting / unify windows batch script with linux
shell script.
Changes:
- Xnofork is no more needed on windows because argument parsing is working now
- use run-args + fix classpaths (portable itw with deps)
- fix CRLF in bat files
I tested it on windows 7/10 and it works great.
I noted windows shortcuts work now, except on JDK12 (maybe related to
jigsaw classloader ?)
I have questions about header variables (too many) and why these need
to be absolute paths ?
it could be relative paths if we add ITW_HOME on the top.
Of course, it depends between DIST or BUNDLE modes ... like for
dependencies (win/linux_deps folders)
Please explain how do you plan to make portable (cross-platform) packages ?
PS: I did not split these patch as I prefer you to have a look and
merge on your side or I can merge on my side with your Makefile
changes ...
PS2: you can have a look @github to see complete shell scripts (not diff):
https://github.com/bourgesl/icedtea-web/tree/run-args/shell-launcher
Cheers,
Laurent
Le mer. 23 janv. 2019 à 08:52, Laurent Bourgès
<bourges.laurent at gmail.com> a écrit :
>
> 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 --------------
A non-text attachment was scrubbed...
Name: patch-run-args-win.2.diff
Type: text/x-patch
Size: 30721 bytes
Desc: not available
URL: <https://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20190125/42fa4f1b/patch-run-args-win.2-0001.diff>
More information about the distro-pkg-dev
mailing list