RFR: 8055206: Update SecurityManager::checkPackageAccess to restrict non-exported JDK packages by default

[Mandy Chung]

> On Jan 18, 2017, at 1:23 PM, Sean Mullan <sean.mullan at oracle.com> wrote:
> 
>> Similar to the feedback I suggest for JDK-8168075.  We can move this
>> initialization to the holder class and trigger the initialization in
>> the SecurityManager constructor.
> 
> For now, I would prefer to leave it as is. In an earlier revision, I experimented with delaying the initialization of nonExportedPkgs until checkPackageAccess was called and ran into some circular permission checking issues. It could be moving it to the ctor is ok, but since I have every test passing right now, I'd rather not tinker with it :)

Okay with me.

> 
>>> : Several tests also had to be modified to be granted additional
>>> permission(s) to access the newly restricted packages under a
>>> SecurityManager. JAXP also needed a change to grant additional
>>> permissions to access internal packages that are exported to the
>>> modules that are dynamically created for use with XSLT.
>> 
>> We will have to see if any dynamic generated bytecode in the field
>> will need access to internal API like XSLT case.
> 
> Yes. I have checked several other use cases in the JDK that create dynamic modules (nashorn, rmi, jmx) and not found any issues.

Thanks for the confirmation.
Mandy