-
Bug
-
Resolution: Fixed
-
P2
-
14
-
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
-