IcedTeaWeb questions

[Jiri Vanek]

> I went here: https://icedtea.classpath.org/wiki/IcedTea-Web#1.8
> then here: https://mail.openjdk.java.net/pipermail/distro-pkg-dev/2019-March/041321.html
> (which is an e-mail from you I believe)
> In that e-mail provides links to the msi installer:
> http://icedtea.wildebeest.org/download/icedtea-web-binaries/1.8/windows/itw-installer.msi

ok. TY!
> 
>> In native launchers, PATH is also scanned for possible JRE. Would this solve your issue?
>> If yes, then I would go with PATH approach.
>> also JAVA_HOME should bealready working for you, and also you can set JRE in
>> $CONFIG_HOME/icedtea-web/deployment.properties. Would that work for you?
>> If not, then your solution may go to play.
> 
> I don't know if you are familiar with MacOSX. Apple provides some

Not at all! I think it must be obvius:( Sorry and thanx for explanations.

> wrapper for java and javaws that basically say: *Please install a JRE
> if you don't have one*. If you have multiple JRE installed then you
> can select between them, set the default etc via
> /usr/libexec/java_hom. In this scheme java is always in /usr/bin/java
> (the wrapper) and javaws is in /usr/bin/javaws. /usr/bin/javaws looks

That mean it is on path I belive. So enhance shell launchers like to traverse path maybe good idea.

> for the actual javaws in: /Library/Internet\
> Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/bin/javaws.
> JRE itself is located on
> /Library/Java/JavaVirtualMachines/adoptopenjdk-11.jre/Contents/Home
> 
> So I looked a bit at launchers/rust-launcher/src/utils.rs :
> get_jdk_from_given_path_testable but I am not sure what it would in
> the MacOSX case. I can't tell without testing if such an approach
> would work.

I owuld bet it will.  Still worthy to add into shell lauchers. In shell launchers, the issue is that
the waterfall rustlaunchers do when seeking for JRE, is producing unreadable code.
> 
> Thanks for $CONFIG_HOME/icedtea-web/deployment.properties. I hadn't
> realized that you set the JRE there. This implies that javaws runs
> with a JRE and you can configure another to run the application.
> Unfortunately it doesn't help you to pickup the right JRE to run
> javaws.

Ugh... That is exactly what it should do. If you have JRE specified here, it will be second most
promoted after java_home.  javaws and application are alwyas run in same jdk. Really.
> 
>> If you wish to fix it, then likely new deployment property can be introduced, to close the console
>> of forking VM . Looking forward for PR :)
> 
> Thanks for confirming that there is no such setting. I will consider a
> PR when the itch grows to pain levels.
> 
>>
>> I had never before hear about those two. sorry.
> 
> Oh here there are:
> https://alvinalexander.com/java/java-application-name-mac-menu-bar-menubar-class-name

Oh I see. That can be fixed. If -Xdoc will be in jnlpfile, then it will - on mac - enforce forking
of new jvm, which will have correct title. The disadvantage is, that it is mac only, and proper
check for mac (java -Xdoc must not exit, as it does onlinux and win) wil be necessary.
> 
>>>
>>> c) java-vm-args attribute in the resource/java jnlp element looks
>>> like that is not honored, is it? Are there any plans to support
>>> java-vm-args in the feature?
>>
>> The title belongs to jnlp's element title. Is it not honored too?
>> speaking abot java-vm-args, not sure what you are reffering to. -J params are supported.
> 
> -J needs to be specified in the command line when javaws is executed.
> java-vm-args is set on the JNLP, so javaws forks the java with these

And java-vm-args are supported. But are based on enumeration. Xdoc is now misisng (especially
because being mac specific)

> arguments. Somewhat risky I may add but it is there:
> https://docs.oracle.com/javase/8/docs/technotes/guides/javaws/developersguide/syntax.html
> 
>>
>> ....Oh! now I realised - By console - you mean ITW console or terminal of your OS?
>>
> 
> I mean ITW console with the advance panel and the details button.
> 
> So that would require two PRs
> 
> 1) Close ITW console on startup

Yes, to enable hiding of first console after second vm is launched is good patch.

> 2) Start with details off in the second console

Not sure with this. It canbe easily added as new deployment property to specify what to see, but as
defualt, I would alwyas vote for all. WDYT?
> 
>> Similarly, I had also wrongly answered  your first question. This is your OS behaviour and os setup.
>> I doubt there is anything we can do around. The second VM is again spawned via javaws.sh. And your
>> os is opening terminal for each os. Using the javaws binary would solve this, but it means that
>> somebody have to build native rust launchers on mac. Are yu voulenteer? it would be awesome :)
> 
> I think you answered correctly. I don't have two terminals or two
> shells. I just have two java consoles.

Thanx for clarification!
> 
>>
>> This is first time I hear about -Xdoc.  Jnlp's <title> is not what you desire?
>> You can pass jdk arguments to jvm via javaws -J-Xdoc, but I really do not see -Xdoc in openjdk's
>> swithces.
> 
> Here it is: https://www.oracle.com/technetwork/articles/java/javatomac-140486.html
> The problem is that title does not set  the application name in
> MaxOsx. Yes I can do it in the command line but I want to do it from
> the JNLP. That means to seth -Xdock:name when jnlp title is set.
> That would require a third PR.

Indded. As I wrote above, should be easily doable. Again thanx for confirmation.
> 
> I really appreciate your input. Now I am understanding things much better.
> 
> Thanks again. You have covered my questions 100% If you need any other
> clarification let me know.
> 
happy to help! Loking forward to review your PRs:)

It is starting to be obvious that we need rust launchers on mac too....


  J.


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