IcedTeaWeb questions

Jiri Vanek jvanek at
Thu Jun 13 13:47:43 UTC 2019

> I went here:
> then here:
> (which is an e-mail from you I believe)
> In that e-mail provides links to the msi installer:

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

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


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

More information about the distro-pkg-dev mailing list