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

[Jacob Wisor]

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

> 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