Record and annotation values

forax at forax at
Mon Apr 9 06:16:26 UTC 2018

----- Mail original -----
> De: "Brian Goetz" <brian.goetz at>
> À: "Remi Forax" <forax at>, "amber-spec-experts" <amber-spec-experts at>
> Envoyé: Dimanche 8 Avril 2018 23:33:33
> Objet: Re: Record and annotation values

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

I agree, i do not think it's a good idea to introduce record as annotation value just because we can but that's not the reason why i think we should introduce record as annotation value.

There is a lot of time where you can construct an annotation with invalid values but those invalid annotation will not be catch at compile time but at runtime.
By example,  
  @Test({ignore=false, timeout_value=-3, timeout_unit=SECOND})

So having a way to specify a contract for annotation values will make Java more safe.

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

yes, a specfic attribute is perhaps a better,
i wonder if the information in the RecordSignature should not be part of the Extractor.


> 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

More information about the amber-spec-observers mailing list