RFR: 7103570 AtomicIntegerFieldUpdater does not work when SecurityManager is installed

Paul Sandoz paul.sandoz at oracle.com
Fri Apr 20 12:11:47 UTC 2012


On Apr 20, 2012, at 2:07 AM, David Holmes wrote:

> 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/
> 

Looks fine to me.


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

Yes, preferably just once :-) I was just indicating previously there were two levels of wrapping.

Paul.


> 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<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