On Thu, Sep 13, 2018 at 3:03 PM Sean Mullan <sean.mul...@oracle.com> wrote: > > This is a SecurityManager related change which warrants some additional > details for its motivation. > > The current System.setSecurityManager() API allows a SecurityManager to > be set at run-time. However, because of this mutability, it incurs a > performance overhead even for applications that never call it and do not > enable a SecurityManager dynamically, which is probably the majority of > applications.
What kind of performance overhead? > For example, there are lots of "SecurityManager sm = > System.getSecurityManager(); if (sm != null) ..." checks in the JDK. If > it was known that a SecurityManager could never be set at run-time, > these checks could be optimized using constant-folding. I think they could be optimized using constant-folding either way, if something like SwitchPoint were used instead of a plain field; am I incorrect in my understanding? The reason I ask is... (see below) > There are essentially two main parts to this change: > > 1. Deprecation of System.s[etS]ecurityManager() We (JBoss) use this method to configure some things at run time (like customizing the Policy) before installing our security manager, so this would be not so great for us. -- - DML
