On Thu, 10 Dec 2020 22:59:16 GMT, Mandy Chung <mch...@openjdk.org> wrote:
>> 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. This indeed needs some >> investigation what the best way to address this. > > 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. Target this fix for jdk16 (https://github.com/openjdk/jdk16/pull/14). ------------- PR: https://git.openjdk.java.net/jdk/pull/1706
