RFR: 8257596: Clarify trusted final fields for record classes

[Mandy Chung]

On Thu, 10 Dec 2020 22:56:34 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Marked as reviewed by chegar (Reviewer).
>
> Hi Remi,
> 
>> For me, it's backout JDK-8247444, as i said on the amber-spec-expert, i prefer VM to be oblivious about java.lang.Record.
>> And in the future, the real fix is to change the spec of Field.set() to say that it's only allowed for plain java classes and have the implementation to directly asks the VM is a non static field is trusted or not.
> 
> This reply was before you realized that records are are permanent Java SE 16 feature :-)  If the future ended up requiring/desiring to allow final fields of a record class be modifiable reflectively (I double that!), `Field::set` spec can be updated to remove that restriction with no compatibility risk
> 
>> And there are also a related issue with the validation of the InnerClass/Enclosing attribute were the VM does a handshake between the inner class attribute and the enclosing class attribute when calling Class.getSimpleName(), again using the JLS definition of what an inner class is instead of using the VM definition, the content of the InnerClass attribute with no validation.
> 
> It's the implementation details of the core reflection how to determine if a class is a member of another class.   The `getSimpleName` spec and other related APIs (see JDK-8250226) need to define the behavior when there is an issue in determining the declaring class.

I have created a new branch off jdk16: https://github.com/mlchung/jdk16/tree/8257596.  It fixed the attribute name as Harold pointed out.   

@hseigel tier1-tier3 and jck-runtime:vm and jck-runtime:lang tests all passed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1706