RFR 6997010: Consolidate java.security files into one file with modifications

[Sean Mullan]

On 07/22/2014 10:28 PM, Wang Weijun wrote:
>
> Please review the code change at
>
> http://cr.openjdk.java.net/~weijun/6997010/webrev.00/
>
> The fix consolidates java.security-<platform> files into one with
> #ifdef directives.
>
> There are several major changes:
>
> 1. Creation of file is moved from CopyFiles to GenerateData, since we
> are really generating something now. Said that, the source data is
> kept in src/share/lib/security instead of make/data. I am OK with
> moving it if anyone desires.
>
> 2. The new tool MakeJavaSecurity includes the function of old
> AddToRestrictedPkgs. MakeJavaSecurity includes a new argument to deal
> with the platform dependent entries. The restricted.pkgs argument is
> also changed from a list of entries to a file name, so that we can
> also support the same #ifdef mechanism inside restricted.pkgs.
>
> 3. The new consolidated java.security supports #ifdef and #ifndef. It
> is not necessary to support #else or (and|or) of multiple #ifdef's
> now.
>
> 4. *IMPORTANT*: In order to easily maintain platform-related entries,
> every line (including the last line) in package.access and
> package.definition MUST end with ',\' now. A blank line MUST exist
> after the last line. This avoid ugly lines like
>
> #ifndef windows entry1. #endif #ifdef windows entry1.,\ entry2
> #endif

What happens if someone (inevitably) adds a new package to the list and 
forgets to do either of these? Does it result in a build failure?

Otherwise looks good, although I think it would be useful to write an 
additional test to make sure the correct providers are installed and 
ordered correctly on the different platforms, something similar to the 
java/lang/SecurityManager/CheckPackageAccess.java test but specific to 
providers.

Thanks for doing this, it will really help maintaining this file going 
forward!

--Sean

>
> The MakeJavaSecurity tool will strip the trailing ",\" from the last
> line to make the file exactly the same as before, although personally
> I don't think it's really necessary since the following empty line
> will terminate the entry automatically.
>
> Thanks Max
>