On 1/13/2017 10:30 AM, Sean Mullan wrote:
On 1/12/17 3:53 PM, Mandy Chung wrote:
On Jan 11, 2017, at 5:34 AM, Adam Petcher <adam.petc...@oracle.com>
wrote:
Please review the following bug fix:
http://cr.openjdk.java.net/~apetcher/8168075/webrev.00/
This fixes a bug in which a permission check would try to load
resources while the system class loader is being initialized.
Resources cannot be loaded at this time, so this change ensures
that the resources are loaded earlier.
This seems a reasonable approach. There is a slight overhead for
this change when the resource bundle is never used but it’s not an
issue since the initialization of a security manager is not cheap
anyway.
It may be helpful to add a check to ensure that the resource bundle
is loaded either VM.isBooted() or initLevel != 3. It would make it
clear of this circular bootstrapping issue.
You do this in SecurityManager class initialization. Have you
considered doing it in the SecurityManager constructor? As Claes
clarified, SM is loaded but not initialized during early VM startup.
So no issue to do it in clinit. The alternative is to do it in the
constructor as lazy initialization.
I don't see any particular performance advantage of moving it to the
constructor. The SM will be initialized and instantiated in phase 3
before it initializes the system classloader. Did you have another
concern in mind?
ResourcesMgr.java Is the doPrivileged necessary? It’s old code
written long ago. Perhaps we should file a bug to clean this up
later.
At this point in JDK 9, it's probably better to leave it alone until
we have more time to evaluate it. Adam, please file a bug to look into
this more, unless you can quickly determine that it is needed.
JDK-8172808 created.
--Sean
