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