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