/hg/icedtea-web: Improve PolicyTool launch method in PolicyPanel

[Andrew Azores]

On 01/27/2014 02:17 PM, Jacob Wisor wrote:
> On 01/27/2014 03:39 PM, Jiri Vanek wrote:
>> ...
>>>> +     * @param filePath a {@link String} representing the path of 
>>>> the file to
>>>> attempt to open
>>>> +     * @throws Exception if any sort of exception occurs during 
>>>> reflective
>>>> launch of policytool
>>>> +     */
>>>> +    private static void reflectivePolicyToolLaunch(final String 
>>>> filePath)
>>>> throws Exception {
>>>> +        Class<?> policyTool =
>>>> Class.forName("sun.security.tools.policytool.PolicyTool");
>>>
>>> What about JRE 6? You could catch a ClassNotFoundException here and 
>>> then try
>>> to get
>>> sun.security.tools.PolicyTool. And, if that fails, well then... Blow 
>>> up! :-D
>>
>> Well - why yes? The jdk6 is dead. We are dealing with slowly, but its 
>> true. The
>> command exec is what matters. The second one is fallback.
>>
>> If you have non-policytool command, non jdk7 system. Please go on and 
>> fix.
>> Otherwise I do not believe it is worthy.
>
> The reason I mentioned this is because as Andrew wants to backport 
> this patch to 1.4

I'm sorry - what? Please go back and re-read the mail from three days 
ago where I posted the backport patch.

> and many machines will probably still be running on a strict 
> combination of IcedTea-Web 1.4 on JRE 6 (for various reasons), the 
> fallback for the *new feature* introduced by it will not work on this 
> combination. Your proposed quick "fix" is not always easily possible, 
> eg. because some other major software requires JRE 6 to run. This is 
> also one reason why I called this patch a *new feature* and am against 
> backporting it. But, if the patch is going to be backported then 
> please also make sure that IcedTea-Web 1.4 will run on JREs that were 
> still in wide use during its initial release, like JRE 6. Yes, even 
> when resorting to a fallback.
>
> As a side note: Those version numbers have a meaning indeed. They are 
> not just some sort of fancy way for naming things. They define feature 
> sets and dependencies. This is especially important for business people.

Anyway. If this patch is going to get backported to 1.4 then I think 
you're right and 6-compatibility should be taken into account (ie 
reflective fallback should also check for PolicyTool in its old 
package). I'm not sure how much we care about this for the 1.5 patch, 
but perhaps it would still be worth adding. I doubt there are very many 
users who are going to be using ITW 1.5 alongside Java 6, and of those 
users, how many are going to be trying to launch PolicyTool from the 
PolicyPanel *and* relying on the fallback reflective launch? To me this 
sounds like very very few users if any. But, it also isn't really too 
much more work, it will just make the PolicyPanel messier with all the 
extra reflective fallback cruft. If it's already being done for 1.4 then 
it might as well get done for 1.5, however.

>
>> And if we will nit pick -what about gnu classpath ? ;)
>
> Classpath or any other JRE do not apply as an argument here because we 
> always assumed that this a OpenJDK/Oracle JRE specific feature. J2SE 
> leaves it up to the JRE vendor on how to implement the configuration 
> of the default SecurityManager and default Permissions.
>
> Jacob

Thanks,

-- 
Andrew A