[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-distro-pkg-dev
Subject:    Re: IcedTeaWeb questions
From:       Jiri Vanek <jvanek () redhat ! com>
Date:       2019-06-14 14:48:19
Message-ID: 47ffb387-9310-2dea-2f60-d6881f9af588 () redhat ! com
[Download RAW message or body]

On 6/14/19 4:32 PM, Vassilis Virvilis wrote:
> On Thu, Jun 13, 2019 at 4:48 PM Jiri Vanek <jvanek@redhat.com> wrote:
> 
>>> 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.
> 
> Me neither. This is what I figured the last week trying to support some users.
> 
>> 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.
> 
> Yes I can see it now. deployment.properties is read by the shell. Nice.

And by rust ones.
> 
>> And java-vm-args are supported. But are based on enumeration. Xdoc is now misisng (especially
>> because being mac specific)
> 
> In my tests I wasn't able to pass any args to the application jvm via
> jnlp. I don't know what 'based on enumeration' means though.

The netx is searching for xmx, xms and few others. If it founds them,  then it spawn new JVM. Xdoc
is another one who will need to be added here. With exception of being mac only.
> 
>> 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?
> 
> I would think to have it open only for developers or users that are
> debugging jnlp loading issues. For normal users with working setups I
> would prefer it to be closed. The original netx implementation had
> only one java console not two and this surprises and annoys some
> users. Anyway if there was a config option to auto close after jvm
> startup that would be great and more than enough.

I moreover agree. Still the default is enabled+hidden.  So once you show it by purpose, it assumes
you are already developer, and thus you wish to see all the issues. and that means issues from both
runs. It could be read via some socket or pipe (as it was from plugin) but that can leak platform
independence with unwanted overhead.
> 
> Thank you very much for all the insights and the welcoming atmosphere.
> I will try to play with application  name setups and the rust launcher
> and maybe I can provide feedback in PR form.


TYVM for this effort! Corssing fingers!

  J.
[prev in list] [next in list] [prev in thread] [next in thread]