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