[ 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" <kev...@google.com>
À: "Gunnar Morling" <gun...@hibernate.org>
Cc: "amber-dev" <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 <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. | kev...@google.com
