RFR: 7103570 AtomicIntegerFieldUpdater does not work when SecurityManager is installed (original) (raw)

David Holmes david.holmes at oracle.com
Fri Apr 20 00:07:45 UTC 2012

Thanks Paul that was a good set of suggestions. I had overlooked the change in the exceptions being thrown.

Updated webrev:

http://cr.openjdk.java.net/~dholmes/7103570/webrev.01/

I can't do quite exactly as you said because the NoSuchFieldException has to remain wrapped in one RuntimeException.

David

On 19/04/2012 11:53 PM, Paul Sandoz wrote:

Hi David,

I think you can retain the same exception throwing behavior (plus no casts are required to Field) as before by doing: try { field = AccessController.doPrivileged(new PriviledgedExceptionAction() { public Field run() throws NoSuchFieldException { return tclass.getDeclaredField(fieldName); } } } catch (PrivilegedActionException e) { throw (NoSuchFieldException)e.getException(); } Thus avoiding a NoSuchFieldException being nested RuntimeException which is further nested in a RuntimeException. Paul. On Apr 19, 2012, at 1:35 PM, David Holmes wrote:

http://cr.openjdk.java.net/~dholmes/7103570/webrev/

Basic fix is to call getDeclaredField() inside a doPrivileged block. In addition the call to checkPackageAccess is now conditional - it allows for, for example, a class in sun.misc to create a field updater for another class in sun.misc. Finally the @throws spec for newUpdater has been expanded to say: @throws RuntimeException with a nested reflection-based exception if the class does not hold field or is the wrong type, + or the field is inaccessible to the caller according to Java language + access control This last part requires CCC approval which I will initiate. I have a glitch with running the test under jtreg but hopefully that will get sorted soon (jtreg fails if a security manager is installed). Thanks, David Holmes ------------

More information about the core-libs-dev mailing list