[rfc][icedtea-web] try to properly(?) react on java/j2se version

[Jiri Vanek]

On 02/03/2015 04:40 PM, Jiri Vanek wrote:
> On 02/02/2015 08:35 PM, Jie Kang wrote:
>>
>>
>> ----- Original Message -----
>>> hi!
>>>
>>> I was recently acknowledged with ITW misbehaving when interpretting
>>> java/j2se's version attribute.
>>> When they "dont match" then itw simply continues(???)
>>>
>>> The useces I was informed about, was, that the application was known not to
>>> run on jdk7
>>>
>>> So they included `version="1.6.0"` and itw happily runs without any warning.
>>>
>>>
>>> I'm adding reaction - in strict mode dye, in non strict mode popup window.
>>>
>>> Actually  - I'm absolutely unsure what to do with this case...
>>
>> Hello,
>>
>>
>> Is there a website I can go for testing this? Or could you create a reproducer for this?
>
> one BAD example is
> http://argouml.tigris.org/files/documents/4/383/ArgoUML-stable.jnlp
>
> the behavior of this appis exactly why not to do what i did.
>   - forgoten jnlp app
>   - rewuires exactly 1.4.whatever
>   => unwonted dialog rise up
>
>
>>
>>
>> +    public static class JreVersion extends Version{
>>
>> I'd strongly prefer this to be in it's own file along with it's own tests.
>
> hmhhm.. why? :(( It is so single case, that I dont wont to puboic it more.
>>
>> As well can you add some comments to the differences between JreVersion and Version. When do we
>> use Version instead of JreVersion and when do we use JreVersion instead of Version? It isn't 100%
>> clear to me at the moment;;
>>
>> +                    throw new RuntimeException("Strict run is  deffined, and your JRE - " +
>> getJreVersion() + " - dont match requested JRE - " + v);
>>
>> s/deffined/defined
>>
>> Should this string be localized?
> nope - localised exceptions are root of another evil.
> But I will localize the message which goes to dialogue - if some dialogue appears at all.
>>
>> +        //this fails, do we need workaround?
>> +        //Assert.assertTrue(new Version("1.5-").matches("1.4"));
>>
>> I think rather than workaround, a patch to the Version class would be appropriate.
>
> I will change it to:
>   +        //this fails, do we need patch it?
>   +        //Assert.assertTrue(new Version("1.5-").matches("1.4"));
>>
>>
>
> My concerns are that - is nowhere speciifed.. and dont give much sense...
>
>
>
> A way - I'm thinking of two changes
>
> for this patch:
>   when invalid jdk is detected
>   - strict
>     - warning to console
>     - strict mode -  dialogue popup, with "run: yes/no"
>   - nostrict,
>    - only warning to console
>
> Corrct jdk detected
>   - jsut info to console.
>
>
>

here its. What do you think?


J.
>
>
> For future:
>   - I think ITW needs some mechanism to rember decision on those swarms of dialogues
>   - some big work here will be needed and I started to work on prototype
>
>
> J.
>
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: supportVersions_3.patch
Type: text/x-patch
Size: 7633 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20150211/3f5804e7/supportVersions_3-0001.patch>