Annos on records
Brian Goetz
brian.goetz at oracle.com
Tue Apr 10 21:19:16 UTC 2018
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.
>
> 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
> <brian.goetz at oracle.com <mailto: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" <kevinb at google.com
> <mailto:kevinb at google.com>>
> À: "Gunnar Morling" <gunnar at hibernate.org
> <mailto:gunnar at hibernate.org>>
> Cc: "amber-dev" <amber-dev at openjdk.java.net
> <mailto: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
> <gunnar at hibernate.org <mailto: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. |
> kevinb at google.com <mailto:kevinb at google.com>
>
>
>
>
>
> --
> Kevin Bourrillion | Java Librarian | Google,
> Inc. |kevinb at google.com <mailto:kevinb at google.com>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20180410/4bf4418f/attachment.html>
More information about the amber-spec-experts
mailing list