IcedTeaWeb: using java 9 run args ?

[Jiri Vanek]

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.

With shell launchers, one can do this on his own. No meter of complexity. In native lunchers, this
is impossible without recompilation.

So my current mindset is pointing to the launcher.properties file, included in ITW_HOME or (for
distributions) in some known path.
This should contains fileds like:
jvm_default_args=xmx...--add-reads...--patch...
(note that this do not handle)
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... ?

Something else?

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)

Thoughts?
  J.

On 12/14/18 4:08 PM, Jiri Vanek wrote:
> On 12/13/18 11:16 PM, Laurent Bourgès wrote:
>> Hi Jiri,
>>
>> You're right, it is time for me to contribute back better launchers (shell/batch) to ITW 1.7...
>>
> 
> Do you really wish to put cycles into bat files? They are for strange use.... Still tight, they may
> serve as secondary source of knowledge to rust lunchers.
> 
>> However it is quite difficult for me to understand the usual way to do it:
>> - I mainly experimented fixes in generated scripts (install folder) to test changes.
>> We should first agree on the final output:
>> Do you agree adding a new class ParseVersion to perform the java version tests (compatible with
>> linux / windows...) ?
>  -yes
> 
>> Do you agree adding itw-run.args for global jigsaw options as proposed ? For now I let this static
>> file in the root itw folder.
> 
> Yes. this file is good idea. for distribution builds, the root itw folder is  not enough.What is
> your current syntax? Eg jdk.jsobject is pathecd conditionally (but that one can remain hardcoded)
> 
>>
>> I still want to have windows / shell scripts working on both JDK8 & 11.
> Really bats?  Well then we speek about three launchers - rustl bat and sh. I agree all three shoould
> be as aligned as possible and as versatile as possible.
> 
>> It requires many small changes.
>> For instance, JDK8 can use rt.jar, jfxrt.jar, nashorn but not jdk11 ...
> Tho have those on cp is harmelss for JDK11.  So what is missing is search for jdk11 versions of fx
> (nashorn is just another module isnt it? and will be removed?  Search for custom FX is doable (once
> the goal have clear specification)
> More tricky is pathcing not existing modules. Still it canbe handled by logic. (it canbring torubles
> to .args file you are thinkging with)
> 
>> That's not clear to me how generic should stay these scripts (independent of JDK version) or
>> customized by build or install scripts ... it is confusing me.
> They should be jdk independent.  And build/isntall shoudl affect them in reasonable way. I'mnto sure
> if I understand your question. Which is what rust lucnhers shoulr be doing much better then current
> shells.
> 
>> I compared again win vs linux scripts and ITW_HOME is only defined in windows batch whereas it is a
>> good variable to have in linux scripts too to avoid having many times to full path.
> 
> rust lunchers are supporting this approach. They support both portable and distribution builds. Thy
> support ITW_LIBS_DIR, which is (moreover) replacement for ITW_HOME.
> 
>> How could we simplify all these paths / variables refering paths or relying on the
> 
> Pasths maybe can be simplifed. Do you have something in mind?
>> deployment.properties ?
> 
> But proeperties hardly. That is following oracle javaws.
> 
>>
>>
>> - Today I quickly looked at the Makefile / configure scripts to see how it works (variable / path
>> substitution, sed scripts ...) and I do not know how to proceed.
>> Could you give me directions how to proceed with adding new variables (autoconf, configure, make ...) ?
> 
> What variable would yuo like to add and what it should do?
> See my today patch on rust lunchers. It can give you some answers.
> 
>>
>> On my work-station, I made also few hacks in Makefile:
>> - always generate/install windows launchers (bat files), not only when WINDOWS is defined.
>> Would you agree adding another flag(s) to generate shelll / batch files in autoconf ?
> Strange idea:)
> Here I would vote for adjsuting :
>  jvanek  jvanek  16:02:57  ~  Desktop  icedtea-web  default +  $  sh configure --help | grep
> launchers
>   --enable-shell-launchers
>                           Enable build of legacy shell launchers
> 
> 
> To change it to yes/no/both
> 
> Note that those change may be wrongly passable to 1.7 I would rather focus to 1.8 and native
> launchers. Still I understand your desire to have them.
> 
>> - ignore bash completion (failing on my setup) as I do not want to alter my linux install (no system
>> integration): same question ? 
> 
> Bash completion isalready configurable:
>  sh configure --help | grep bash  -A 1
>   bashcompdir value of completionsdir for bash-completion, overriding
>               pkg-config
> 
> This is somehow hypercomaptible. So set it to your local install.
> Anther configure switch to disable it is also ok by me.
>>
>> Finally I would like to achieve making on linux a linux + window build package having all necessary
>> bits (jar, splash, scripts) that will work on win/linux platforms (without plugins, no native libs):
> plugin si dead. Its code and make will be ropped in 1.9
> 
>> it could be a minimal cross-platform package (redistribuable as a standalone zip file ~ 2mb)
> 
> Yes. In this point of view, your batfiles have perfect sense. Can this be done with rust? I doubt:(
>>
>> Thanks for your advices,
>> I will take time to inspect my current local repo and try to figure out a way to simplify scripts.
>>
> 
> Tyvm for ideas.
>   I hope I will be for some help for you
>     J.
> 


-- 
Jiri Vanek
Senior QE engineer, OpenJDK QE lead, Mgr.
Red Hat Czech
jvanek at redhat.com    M: +420775390109