RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails to throw IllegalAccessException for final fields

Adam Farley8 adam.farley at uk.ibm.com
Wed Jan 30 15:52:59 UTC 2019

Hi Mandy,

CSR has been raised: https://bugs.openjdk.java.net/browse/JDK-8218061

The webrev I used includes John's comments, your additions, the 
and I also took the liberty of moving the unreflectField method underneath 

the unreflectSetter method, because it seemed strange that it was located 
between unreflectSetter and unreflectGetter.

Online webrev has been updated to include these changes: 

Thoughts and comments, from you and others, are welcome as always.

Best Regards

Adam Farley 
IBM Runtimes

Mandy Chung <mandy.chung at oracle.com> wrote on 23/01/2019 19:18:09:

> From: Mandy Chung <mandy.chung at oracle.com>
> To: Adam Farley8 <adam.farley at uk.ibm.com>
> Cc: core-libs-dev <core-libs-dev at openjdk.java.net>
> Date: 23/01/2019 19:17
> Subject: Re: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails 
> to throw IllegalAccessException for final fields
> Hi Adam,

> On 1/23/19 8:33 AM, Adam Farley8 wrote:
> Hi Mandy, 
> Food for thought: 
> - From John's email, it looked like he was advocating a 
> clarification change to the spec (which requires no CSR).

> While the new behavior was intended when the spec was written, this 
> fix changes the current behavior and a CSR will be needed to 
> document the incompatible change.  The current behavior of 
> unreflectSetter may return a MethodHandle of a static final Field 
> object with accessible flag set and then invoke MH to change the 
> static final field value.  The new behavior of unreflectSetter 
> throws IAE as static final FIeld does not have write access.
> - * @throws IllegalAccessException if access checking fails 
> + * @throws IllegalAccessException if access checking fails, 
> + * or if the field is {@code final} and write access 
> + * is not enabled on the {@code Field} object 

> - A test case is attached to the bug. It displays "current 
> behaviour", but doesn't show a clear "pass" or "fail", because at 
> the start of this there appeared to be disagreement over what the 
> correct behaviour was. 
> - Good idea on the new line. I'll add it to the webrev shortly. 
> - As for the comments, I think I see what John was going for, but I 
> don't understand his first change. This seems to be the opposite of 
> what we're trying for here. 
> +     * In the case of a field setter function on a {@code final} field, 

> +     * finality enforcement is treated as a kind of access control, 
> +     * and the lookup will fail, except in special cases of 
> +     * {@link Lookup#unreflectSetter Lookup.unreflectSetter}. 
> Perhaps he means it will still fail, but for the reasons we've 
> discussed rather than anything connected to access control? 

> http://cr.openjdk.java.net/~mchung/jdk13/webrevs/8216558/webrev.01/
> This webrev showing @throws change should show the spec 
> clarification on findSetter and findStaticSetter that throws IAE 
> when looking up a setter on a final field and the spec of 
> unreflectSetter states that it will return a method handle only if 
> the corresponding call to Field::set returns normally.    This 
> webrev is not a review request but rather showing the fix we are 
> discussing here.
> Hope this clarifies it.
> Mandy

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

More information about the core-libs-dev mailing list