JDK-8255560 : Class::isRecord should check that the current class is final and not abstract
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.lang
  • Affected Version: 16
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2020-10-28
  • Updated: 2020-12-17
  • Resolved: 2020-12-07
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 16
16 b28Fixed
Related Reports
CSR :  
JDK-8257520 - Class::isRecord should check that the current class is final and not abstract
Relates :  
JDK-8255342 - Remove non-specified JVM checks on Classes with Record attributes
Relates :  
JDK-8257596 - Clarify trusted final fields for record classes
Description
The removal of non-specified JVM checks on classes with Record attributes JDK-8255342, has resulted in more types of loadable classes that may contain a Record attribute. Now that these checks are not performed by the JVM anymore, Class::isRecord (and by extension Class::getRecordAttributes) may return values for classes that are not wellformed record classes (as per the JLS), .e.g. for non-final classes or for abstract classes.

Core Reflection, Class::isRecord, already asserts checks that the JVM does not, e.g. that the direct superclass is java.lang.Record.
Comments
Changeset: 5a03e476 Author: Chris Hegarty <chegar@openjdk.org> Date: 2020-12-07 11:02:52 +0000 URL: https://git.openjdk.java.net/jdk/commit/5a03e476
07-12-2020
RE: ���The Record Attribute - What does it mean to be a record at runtime��� In order to claim a non-static final field is trusted, such TNSFF must not be modifiable by reflection and method handle (VarHandle does not allow writing on a final field). Unsafe is a lessen concern because it���s unsafe anyway but we should stop what we can. We want records to benefit from TNSFF performance but not care so much normal classes with RecordComponents attribute. JIT optimization is implementation-specific. Checking if a class is a subclass of java.lang.Record should not be expensive. I would suggest to change JIT to check if a class must be final and a subclass of java.lang.Record in addition to the presence of a RecordComponents attribute. In HotSpot implementation term, the current implementation of InstanceKlass::is_record is misleading because it could return true on a normal class. The suggested fix is to change InstanceKlass::is_record to check if _record_components != NULL and it is final and a subclass of java.lang.Record. No change in JVM class file validation. [1] https://mail.openjdk.java.net/pipermail/amber-spec-experts/2020-November/002630.html
12-11-2020
Additional discussion on https://mail.openjdk.java.net/pipermail/amber-spec-experts/2020-November/002630.html
05-11-2020
Some points from the Java Language Specification for record classes: 1. It is a compile-time error if a record declaration has the modifier abstract. 2. A record declaration is implicitly final. 3. The direct superclass type of a record class is Record. Class::isRecord already ensures no.3. This issue considers adding explicit checks in Core Reflection to ensure #1 and #2, since the JVM now allows such classes that contain a Record Attribute to be loaded, that previous to JDK-8255342 would be rejected.
05-11-2020