> On Jan 18, 2017, at 1:23 PM, Sean Mullan <sean.mul...@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
