RFR: 8169993: Class::desiredAssertionStatus should call getClassLoader0 (original) (raw)

David Holmes david.holmes at oracle.com
Sun Nov 20 22:43:56 UTC 2016

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

More information about the core-libs-dev mailing list