Annos on records

Brian Goetz brian.goetz at oracle.com
Tue Apr 10 20:53:43 UTC 2018


MR-JARs busts that restriction; in the main part of your jar, you have

     @Target(A, B)
     @interface Foo { }

and in the 13 section you have

     @Target(A, B, RECORD)
     @interface Foo { }

(that's not the whole thing, but it means you only need wait until you 
_accept_ 13 rather than _require_ 13.)



On 4/10/2018 4:42 PM, Kevin Bourrillion wrote:
> 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/adee8994/attachment.html>


More information about the amber-spec-experts mailing list