Annos on records (was: Records -- Using them as JPA entities and validating them with Bean Validation)

[Remi Forax]

Here is what i've done to support ElementType.MODULE a library that has to work with Java 8, 
adding a target type is usually compatible because the one that add the annotation target is often the one in control of the code that will also consume the annotation. 

In order to work you need to answer two questions: 
- how to create an annotation compatible 8 with a meta-annotation value only available in 9. 
using ASM to add the right value to the annotation meta-annotation is a 10 lines program, 
- how to consume a non existing meta-annotation value, 
i do a switch on the name of the enum instead of doing a switch on the enum itself. 

Rémi 

> De: "Kevin Bourrillion" <kevinb at google.com>
> À: "Brian Goetz" <brian.goetz at oracle.com>
> Cc: "amber-spec-experts" <amber-spec-experts at openjdk.java.net>
> Envoyé: Mardi 10 Avril 2018 22:42:24
> Objet: Re: Annos on records (was: Records -- Using them as JPA entities and
> validating them with Bean Validation)

> If we create a new ElementType.RECORD, the annotation in question won't even be
> able to add that target type until it is ready to require JDK 13 (or whatever)
> as its new minimum version.

> On Tue, Apr 10, 2018 at 1:38 PM, Brian Goetz < [ mailto:brian.goetz at oracle.com |
> brian.goetz at oracle.com ] > wrote:

>> [ moving to amber-spec-experts]

>> I tend to agree. It will take longer to adopt, but it _is_ a new kind of target
>> in a source file, and then frameworks can decide what it should mean, and then
>> there's no confusion.

>> It's possible, too, as a migration move, to split the difference, though I'm not
>> sure its worth it -- add a new target, _and_, if the target includes
>> param/field/method, but does _not_ include record, then lower the anno onto all
>> applicable members.

>> On 4/10/2018 1:34 PM, Remi Forax wrote:

>>> No, not right for me,
>>> a new Annotation target is better so each framework can decide what it means for
>>> its annotation.

>>> It will slow the adoption but it's better in the long term.

>>> Rémi

>>> ----- Mail original -----

>>>> De: "Kevin Bourrillion" < [ mailto:kevinb at google.com | kevinb at google.com ] >
>>>> À: "Gunnar Morling" < [ mailto:gunnar at hibernate.org | gunnar at hibernate.org ] >
>>>> Cc: "amber-dev" < [ mailto:amber-dev at openjdk.java.net |
>>>> amber-dev at openjdk.java.net ] >
>>>> Envoyé: Mardi 10 Avril 2018 19:25:57
>>>> Objet: Re: Records -- Using them as JPA entities and validating them with Bean
>>>> Validation
>>>> On Mon, Apr 9, 2018 at 1:39 PM, Gunnar Morling < [ mailto:gunnar at hibernate.org |
>>>> gunnar at hibernate.org ] > wrote:

>>>>> * Annotation semantics: I couldn't find any example of records with
>>>>> annotations, but IIUC, something like

>>>>> @Entity record Book(@Id long id, String isbn) { ... }

>>>>> would desugar into

>>>>> class @Entity public class Book { private @Id long id, private
>>>>> String isbn; ... };

>>>>> For the JPA entity use case it'd be helpful to have an option to lift
>>>>> annotations to the corresponding getters instead of the fields (as the
>>>>> location of the @Id annotation controls the default strategy -- field vs.
>>>>> property -- for reading/writing entity state). Similarly, Bean Validation
>>>>> would benefit from such option.

>>>> My assumption has been that we would allow an annotation on a record
>>>> parameter as long as it has *any of *{FIELD,METHOD,PARAMETER} as target,
>>>> and that the annotation would be automatically propagated to each
>>>> synthesized element it applies to. Does this sound about right to everyone?

>>>> --
>>>> Kevin Bourrillion | Java Librarian | Google, Inc. | [ mailto:kevinb at google.com |
>>>> kevinb at google.com ]

> --
> Kevin Bourrillion | Java Librarian | Google, Inc. | [ mailto:kevinb at google.com |
> kevinb at google.com ]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20180410/30a99ad8/attachment-0001.html>