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

[Adam Petcher]

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.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?
>
>>
>> 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