RFR: 8061842: Package jurisdiction policy files as something other than JAR

[Bradford Wetmore]

http://cr.openjdk.java.net/~wetmore/8061842/webrev.04/

On 8/25/2016 8:05 PM, Weijun Wang wrote:
> Can you add a new @run line which is the getNameCount()==1 but
> getParent() != policyPath case?
>
> + * @run main/othervm TestUnlimited /unlimited exception

I think I finally developed a stable cross-platform case for this case. 
I've added this case and "unlimited/", which is an acceptable value.

On 8/26/2016 8:57 AM, Sean Mullan wrote:
 > On 08/24/2016 08:21 PM, Bradford Wetmore wrote:
 >> Sean Mullan wrote:
 >>
 >>  > What about setting the default value to "limited"? And then this
 >>  > would only be changed to "unlimited" if the build --enable-unlimited-
 >>  > crypto option is specified?
 >>
 >> I could, but I'm concerned that a build with --enabled-unlimited-crypto
 >> would expect that the compiled-in version default would also be
 >> unlimited and would be surprised with limited.
 >>
 >> Upon Max's suggestion above, I've changed the name of the marker to
 >> "crypto.policy=crypto.policydir-tbd."  Does that work for you?
 >
 > Not really.
 >
 > Why not just leave the property unset (or commented out)? That seems
 > more intuitive to me. What if the placeholder value accidentally never
 > gets replaced?

If the value is unset, commented out, or set to a directory value that 
doesn't exist (e.g. crypto.policydir-tbd), JCE will throw a 
ExceptionInInitializerError on first usage.  If the rewriting script 
somehow doesn't get called as part of the build, then 
security.provider.tbd will likely also cause problems.

I may just not be understanding your concern.

 > Anyway, if time is of the essence, go with what you have. This is not a
 > significant issue.

2pm...(possible fallback to Monday if there aren't any PIT failures)

Brad