I think this is one in the category of "just because you can, doesn't
meant you should." So before discussing mechanisms, let's discuss goals.
Annotations are for metaDATA. The restriction on what you can put in an
annotation stems in part from what you can put in the constant pool, but
busting the constant pool limits doesn't automatically mean its a good
idea to make it an annotation value.
The rule that I've been gravitating towards is: anything that is
important enough to have a _literal form_ in the language, probably is
is a good candidate to consider as an annotation value. The obvious
first candidate is method refs (excluding instance-bound ones). But
even with mrefs in, I'd say no to lambdas, because annotation values
should also be scrutable to annotation processors. (If we had
collection literals, then collections of things that can already go in
annos is probably also a valid candidate.)
Don't forget that just because a record has all-final fields, doesn't
mean its immutable all the way down. And while some notion of
"immutable all the way down" has been a frequent wish-list item, taking
that on just so you can stash records in annotations is definitely tail
wagging the dog.
On the second point (reifying parameter names), while I don't object to
doing this, this can't be the "official" way to get this data. It
should be reflectively accessible, because you need to nominally tie the
constructor arguments to some way of getting their values (getters or
fields). The compiler prototype uses an annotation on the class
declaration that stashes this, but that's just a prototyping hack; this
probably needs a RecordSignature attribute.
On 4/8/2018 4:16 PM, Remi Forax wrote:
Currently annotation values are limited to what is encodable as a constant in
the constant pool.
With Condy, we can expand the number of values that can be encodable as a
constant in the constant pool to the infinity by allowing a reference to any
non-mutable class to be encoded as an annotation values.
For that we need to have a 'protocol' that
- encode an instance of a user defined non-mutable class as a condy by the
- decode an instance of a user defined non-mutable class by the JDK runtime.
Records with their constructors do not provide enough meta-information for
that, the parameter names of the constructors may not be available at runtime.
So i think the constructors parameter names of a Record should be always
recorded (as with --parameters was specified for the constructors) to enable
non-mutable records to be annotation values.