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" <kev...@google.com>
*À: *"Brian Goetz" <brian.go...@oracle.com>
*Cc: *"amber-spec-experts" <amber-spec-experts@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.go...@oracle.com <mailto:brian.go...@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" <kev...@google.com
<mailto:kev...@google.com>>
À: "Gunnar Morling" <gun...@hibernate.org
<mailto:gun...@hibernate.org>>
Cc: "amber-dev" <amber-...@openjdk.java.net
<mailto: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 <mailto: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 <mailto:kev...@google.com>
--
Kevin Bourrillion | Java Librarian | Google,
Inc. |kev...@google.com <mailto:kev...@google.com>
