IcedTeaWeb: using java 9 run args ?

[Jiri Vanek]

Hi Laurent!

How are we with this?

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?

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

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    M: +420775390109