-
Type:
Bug
-
Resolution: Fixed
-
Priority:
P2
-
Affects Version/s: 14
-
Component/s: core-libs
-
b27
-
Verified
A number of issues and/or concerns have been raised recently relating
to the reflective support for records. These arose when finalizing and
completing the runtime CSR. Taken together they seem to lead back to a
few small, but significant, omissions in the spec that would be good to
tighten up. It is important that it be possible to reflectively reason
about record classes in a way that is unambiguous and provides
certainty that the record class is well-formed.
For a class to be a record class, then:
1) It's direct superclass must be java.lang.Record, and
2) It must have a Record attribute.
The entry point to the reflective API for records is the two methods:
Class::isRecord and Class::getRecordComponents.
to the reflective support for records. These arose when finalizing and
completing the runtime CSR. Taken together they seem to lead back to a
few small, but significant, omissions in the spec that would be good to
tighten up. It is important that it be possible to reflectively reason
about record classes in a way that is unambiguous and provides
certainty that the record class is well-formed.
For a class to be a record class, then:
1) It's direct superclass must be java.lang.Record, and
2) It must have a Record attribute.
The entry point to the reflective API for records is the two methods:
Class::isRecord and Class::getRecordComponents.
- csr for
-
JDK-8235583 Clarify record reflective support specification
-
- Closed
-