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" <kev...@google.com>
> À: "Brian Goetz" <brian.go...@oracle.com>
> Cc: "amber-spec-experts" <amber-spec-experts@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.go...@oracle.com |
> brian.go...@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:kev...@google.com | kev...@google.com ] 
>>>> >
>>>> À: "Gunnar Morling" < [ mailto:gun...@hibernate.org | gun...@hibernate.org 
>>>> ] >
>>>> Cc: "amber-dev" < [ mailto:amber-...@openjdk.java.net |
>>>> amber-...@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:gun...@hibernate.org |
>>>> gun...@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:kev...@google.com |
>>>> kev...@google.com ]

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

Reply via email to