IcedTeaWeb: using java 9 run args ?

Laurent Bourgès bourges.laurent at gmail.com
Thu Feb 7 17:45:33 UTC 2019


Jiri,

Le jeu. 7 févr. 2019 à 17:12, Jiri Vanek <jvanek at redhat.com> a écrit :

> So the cross-build-bats is pushed.
>

Yes I got the notification, thx.


> I will elaborate on rest tomorrow.
> I yu adapt your patch to current head, it will be significant help.But is
> not necessary.
>

I will try merging tomorrow as I stay at home (flu).

Thank you too
Laurent

>
> TYVM for cooperation!
>  J.
>
>
> On 2/7/19 3:47 PM, Laurent Bourgès wrote:
> > Hi Jiri,
> > Good to have your feedback.
> >
> >
> > Le jeu. 7 févr. 2019 à 14:27, Jiri Vanek <jvanek at redhat.com <mailto:
> jvanek at redhat.com>> a écrit :
> >
> >     Hi Laurent!
> >
> >     How are we with this?
> >
> >
> > I prefer you to do its integration as my patch has conflicts with your
> changes (am) and my changes
> > are too big so splitting patch is needed, I agree.
> >
> >
> >     Can I commit my "crosscompile" bats patch, and will you adapt?
> >     Maybe it woudl be better if you first adapt your patch to my
> crosscompile patch before I push  - to
> >     test it  abit.
> >     Or do you suggest any other workflow?
> >
> >
> > Ok for me, I will follow and merge. If anything is wrong or missing, I
> will propose smaller patches,
> > sorry.
> >
> >
> >     After crosscompile patch is in, I 'm most likely +1  for pushing
> your new bat+the work on @arg file
> >     (wiht some tuning on my side before push).
> >
> >
> > Excellent plan.
> >
> >
> >     Until now I have not found better solution for jigsaw and other
> params, so also rust launchers will
> >     do as you do - on jdk9+, will add this @file to java cmd. That will
> be done as separate changeset
> >     (by me)
> >
> >
> > Sounds good and easier to do in rust.
> >
> > Thanks a lot.
> >
> > Laurent
> >
> >
> >     Thanx!
> >      J.
> >     On 1/30/19 3:46 PM, Laurent Bourgès wrote:
> >     > 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)
> >
> >
> >     This is ok, I do not intend to add it. If anybody wish, anybody
> can.  And yes, JAVA_HOME can
> >     help a lot.
> >     >
> >     >     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-moduleargs (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
> >
> >
> >     --
> >     Jiri Vanek
> >     Senior QE engineer, OpenJDK QE lead, Mgr.
> >     Red Hat Czech
> >     jvanek at redhat.com <mailto:jvanek at redhat.com>    M: +420775390109
> >
>
>
> --
> 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/20190207/808d561e/attachment-0001.html>


More information about the distro-pkg-dev mailing list