RFR 8168075: Custom system class loader + security manager + malformed policy file = recursive initialization

[Mandy Chung]

> On Jan 13, 2017, at 7:30 AM, Sean Mullan <sean.mullan at oracle.com> wrote:
> 
> On 1/12/17 3:53 PM, Mandy Chung wrote:
>> 
>>> On Jan 11, 2017, at 5:34 AM, Adam Petcher <adam.petcher at 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?
> 

No.  There isn’t any performance difference since such code is invoked when a security manager is created.  I’m okay to push this as is.

Perhaps you can look into it as part of JDK-8055206 since JDK-8055206 has the initialization code too.

Mandy