IcedTeaWeb: using java 9 run args ?

Wed Jan 30 14:46:03 UTC 2019

Hi Jiri,

> I finally finished rewriting / unify windows batch script with linux
> > shell script.
> >
> Taht is bat scripting masterpiece. Congratualtions for gaining eternal
> patience.
>

thanks.

> > 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
>

One remaining difference: windows batch does not parse
deployment.properties (to look up JVM)

The crlg hack is necessary only for args file.  That really have to be
> another patch for that.
> (still we can keep the thread, as many was told here already))
>

I think the contrary, only batch files really expect CRLF line endings. if
you edit using notepad or if you use echo "text" then the line ending is
important.
I suppose jvm arg file are well handled by jvm concerning line endings, so
it is not required to have CRLF in launcher_run.args.

I agree some changes to Makefile.am could be postponed to another patch.

> >
> > 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 ?)
>
> No idea. Adding Joel. to CC. Maybe you will be able to look into it?
> Alex quite IcedTea recently, so there is no windows guy around. I will try
> to get help in RH with
> windows, otherwise windows "support" of itw will depend purely on
> community.
>

>
> > I have questions about header variables (too many) and why these need
> > to be absolute paths ?
> Because in distribution, they ecan be anywhere.
>
> > 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)
> Yes. Bundle mode will be more happy with a bit different setup. Maybe ITW
> will once grow to be more
> standalone then distributions frindly.
>

OK, but it means bundle support needs to re-compute path relative to
ITW_HOME on linux & windows.
In this case, it is not obvious to guess the relative path to a resource
from its absolute path and lots of path are hard-coded in windows batch.
For example:
set "BINARY_LOCATION=%ITW_HOME%/bin/%PROGRAM_NAME%.bat"
set "SPLASH_LOCATION=%ITW_HOME%/share/icedtea-web/javaws_splash.png"

It is not good, as ITW resource may be moved in Makefile or by installer,
so these paths / variables must be maintained if any file is renamed or
moved (netx.jar -> javaws.jar recently !)

Any idea ? It is possible to provide both absolute path & relative paths
but it will be too ugly & complicated.

> >
> > Please explain how do you plan to make portable (cross-platform)
> packages ?
> Nothing like that!
> I will build (and I already am) linux tarablls on linux, and windows
> tarballs on windows.
>

In my tests, I build on linux with batch generated (wrong paths inside)
then create a zip file with linux/win deps.
It works on windows using bundle mode (ITW_HOME pointing to the script dir).
Here is my do-package.sh script (post-build):
ITW_HOME=./install/
mkdir -p $ITW_HOME/linux-deps-runtime/
mkdir -p $ITW_HOME/win-deps-runtime/

# add rhino ?

# linux:
cp tagsoup-1.2.1.jar $ITW_HOME/linux-deps-runtime/

# windows:
cp tagsoup-1.2.1.jar $ITW_HOME/win-deps-runtime/
cp mslinks.jar $ITW_HOME/win-deps-runtime/

zip -r itw-1.8-install.zip $ITW_HOME

> I had attached my version of crosscompiler bats on linux. Compared to
> yours, thay are true on
> windows. Not sure how you were handluing this case. Otherwise they loks
> same asyours. I wrote them
> in Monday, but then fell down with flue which keeps persisting.
>

Yes it is really close. As I am not an automake expert, I prefer your
approach (true on windows).
I will merge your changes and adapt my Makefile patch with less
changes (LUNCHERS
-> LAUNCHERS, run-args, fix CRLF in batch files)

>
> Also i noticed, that *image* as done on linux, with crosscompile on, is
> useless on windows.  Yes,
> you have bats, but windows-deps directory is  corrupoted from linux build.
> Whre I wont to keep this state on 1.7, in head, the only possible solution
> ois to get rid of
> linux/windows*deps*dirs and replace them by singledir deps.  WDYT?
>

I can not build on windows, so I am making a cross-platform package on
linux (jar files + resources + shell launchers).
I agree it would be simpler to put dependencies in a single location (jar
files are cross-platform).

> In addition, yours patch contains also the arg file. I probably agree that
> it is way to go. This
> will do its job for shell launchers. For rust ones, I will need to add the
> cp/bootcp and other java
> switches customisation properties into deployment.properties. WDYT?
>

The aim consist in having all ITW jigsaw args (add-reads / add-opens)
gathered in a single place and minimize the jvm args.
I wonder if rust launchers could do the same (use @launchers-run.args) and
only customize the --patch-module args (netx,plugin,js) and of course,
bootclasspath + classpath (absolute paths)

> >
> > 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
>
> h<t is really splendid work. I\m unable to have nay comment to new bat
> file, except that it loosk
> much better then old one, and that  it do not looks malicious:)
>

Yes I mimic the linux behaviour (functional blocks); only the JVM lookup
(from deplyoment.properties is not handled).

> I'm for its incorporation to both head and 1.7
>
Great !

>
> Few comments to ther chnegs inline:
> ...
> >
> > patch-run-args-win.2.diff
>
> All refactorings/untypos must go as separate patch. Sorry.  Feel free
> topush them without any other
> review. They are making reading of this hard.
>

Please be more precise. You mean fixing typos in Makefile.am (luncher ->
launcher) ?

> > +if ENABLE_WIN_SHELL_LAUNCHERS
> > +# convert Unix newlines (LF) to DOS format:
> > +  line_end_edit_launcher_script=-e "s/\$$/\r/"
> > +else
> > +  line_end_edit_launcher_script=
> > +endif
>
> Only for args file path, right?
>
No, it only fix generated batch files.

> > +if "%MODULAR_JDK%" == "YES" (
> > +  rem warning extra escaping
> > +  set "MODULAR_ARGS=--patch-module
> "java.desktop=%NETX_JAR%;%PLUGIN_JAR%""
>
> why NETX.JAR?
>

%NETX_JAR% means $NETX_JAR ie .../javaws.jar
It is required to patch jdk.desktop module with ITW code (jigsaw issue as
before).

> > +# Support Modular JDK (jigsaw):
> >  MODULAR_JDK="NO"
> > -version=`${JAVA} -version 2>&1 | head -n 1 | cut -d'-' -f1 | cut -d'"'
> -f2 | cut -d'.' -f1`
> > +fullversion=`${JAVA} -version 2>&1`
> > +echo "fullversion: $fullversion"
>
> I would skipp the fullversion: string, and printed $fullversion to stderr
> as are people used from
> jdk/ (?)
>

Not understood. I wanted to avoid calling java -version twice and but show
JVM version once.
What do you propose ?

> >
> > +#echo "CMD: ${COMMAND[@]}"
>
> The commented echo is weird. One is usually running this in -x subshell to
> see details.
>

Ok I will remove such debugging lines.

PS: Would it sound possible for you to handle merging & pushing this patch ?
Anyway I will wait for your changes to Makefiles before merging.

Cheers,
Laurent
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20190130/dd431123/attachment.html>