RFR: 8169993: Class::desiredAssertionStatus should call getClassLoader0

[David Holmes]

Hi Claes,

On 20/11/2016 9:34 PM, Claes Redestad wrote:
> Hi,
>
> On 2016-11-20 02:36, David Holmes wrote:
>> On 19/11/2016 12:52 AM, Claes Redestad wrote:
>>> Hi,
>>>
>>> having classes ask the security manager for permission to access its own
>>> class loader
>>> when probing for assertion status during class initialization appears
>>> pointless.
>>
>> For our internal JDK classloaders perhaps, but you seem to be
>> extrapolating this to all classloaders and all security manager
>> implementations. This would be an observable change in behaviour so at a
>> minimum should be thoroughly examined before being changed.
>
> having desiredAssertionStatus throw an exception during the class
> initialization itself seems like it would break the world, regardless
> of intended classloader and security manager behavior (it's also an
> unspecified behavior for desiredAssertionStatus to throw a
> SecurityException in the first place)

Good point.

> So what would be the possible harm of calling desiredAssertionStatus on
> a class where doing so previously threw a SecurityException (if such a
> case exists): we'll get the answer to the question of whether asserts
> are desired or not for the class. Is this leaking some information
> about the state of the VM? Sure, but unless I'm gravely mistaken this
> is a rather useless bit of information for anyone with malicious intent.

I'm not devious enough to fathom what someone may or may not do in such 
circumstances. I just wanted to make sure that before any SM check is 
removed that it has been given the appropriate thought - which it seems 
it has.

Thanks,
David

> /Claes
>
>>
>> David
>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8169993
>>> Webrev: http://cr.openjdk.java.net/~redestad/8169993/webrev.01/
>>>
>>> Thanks!
>>>
>>> /Claes