RFR: 7103570 AtomicIntegerFieldUpdater does not work when SecurityManager is installed

Paul Sandoz paul.sandoz at oracle.com
Thu Apr 19 13:53:14 UTC 2012


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<Field>() {
        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