RFR: JEP 359-Records: javadoc code
Chris Hegarty
chris.hegarty at oracle.com
Mon Oct 21 16:26:30 UTC 2019
> On 18 Oct 2019, at 13:28, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:
>
> ...
>
> One high-level gripe which is pointing at a failure of the j.l.model API is the lack of a way to get to the canonical constructor directly; we have this issue both in core reflection and source reflection, and I think we should address that, as both serialization and javadoc has to DYI around that.
Core reflection adds just a couple of primitives for record support:
1) Class::isRecord, and
2) Class::getRecordComponents
The getRecordComponents method returns an empty array if the class is not a record or is a record with no components. The not-a-record-class scenario is not ideal, but seems like a reasonable ( given what we have ). If we were to add ( the fingersome ) Class::getRecordCanonicalConsructor, then this method would likely throw an appropriate exception if the class is not a record. If we do this, then maybe the this-class-is-not-a-record behavior of getRecordComponents should be re-examined? I also think that “record” would likely need to be in the method name too, as I’m not sure that the term “canonical constructor” will be enough by itself.
BTW - I agree that such a method would be useful. It also promotes the notion of the “canonical constructor”, even more than is already done by java.lang.Record.
-Chris.
More information about the compiler-dev
mailing list