And MR-Jar obviates using ASM to add the right value to the meta-annotation; you just have two sources, one for 13 and one for prior.

On 4/10/2018 5:07 PM, Remi Forax wrote:
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.



    *De: *"Kevin Bourrillion" <>
    *À: *"Brian Goetz" <>
    *Cc: *"amber-spec-experts" <>
    *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
    < <>> 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.


            ----- Mail original -----

                De: "Kevin Bourrillion" <
                À: "Gunnar Morling" <
                Cc: "amber-dev" <
                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
                < <>>

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

-- Kevin Bourrillion | Java Librarian | Google,
    Inc. | <>

Reply via email to