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 
compiler.
- 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.

Rémi

Reply via email to