----- Mail original -----
> De: "Brian Goetz" <brian.go...@oracle.com>
> À: "Remi Forax" <fo...@univ-mlv.fr>, "amber-spec-experts"
> <amber-spec-experts@openjdk.java.net>
> 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.
Rémi
>
>
> 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
