On Thu, 10 Dec 2020 22:56:34 GMT, Mandy Chung <mch...@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
