Records and annotations

[Remi Forax]

> De: "Brian Goetz" <brian.goetz at oracle.com>
> À: "Kevin Bourrillion" <kevinb at google.com>
> Cc: "amber-spec-experts" <amber-spec-experts at openjdk.java.net>
> Envoyé: Mardi 19 Mars 2019 00:25:58
> Objet: Re: Records and annotations

>>> - Should we treat the cases where @A has a target of RECORD_COMPONENT,
>>> separately from the cases where it does not, such as, only push the annotation
>>> down to members when the target does not include RECORD_COMPONENT? That is, is
>>> the desire to push down annotations based on “well, what if we want to apply a
>>> “legacy” annotation? If so, this causes a migration compatibility issue; if
>>> someone adds RC to the targets list for @A, then when the record is recompiled,
>>> the location of the annotations will changed, possibly changing the behavior of
>>> frameworks that encounter the record.

>> No, we would certainly not require @RC to also be present. If I have released a
>> method annotation it is the current reality that *any* method can use it,
>> including ones I meant it to be applicable to and ones I didn't. I would expect
>> the methods that appear on records to be no exception.

> I'm not sure we're talking about the same thing now? If I have a method
> annotation @MethodsOnly, and I declare

> record Foo(@MethodsOnly int a);

> what am I annotating? It feels a little ad-hoc to say that my intention is to
> annotate only the desugared accessor, because that's the method that is tied to
> `a`. But assuming that is what you're talking about, is this really because we
> want to annotate record components with annotations that don't target record
> components, or is it because we're worried that it will take some time for
> frameworks to add Target.R_C to their annos?

>>> All of which causes me to back up and say: what is the motivation for pushing
>>> these down to implicit members, other than “general friendliness”? Is this a
>>> migration strategy for migrating existing code to use records, without having
>>> to redeclare annotations on the members? And if so, how useful is it really?
>>> Will users want to throw the union of field/accessor/ctor parameter annotations
>>> on the record components just to gain compatibility with their existing code?

>> Say project A has released jars containing method annotations and we're using
>> those annotations on our methods. Under your proposal we are prevented from
>> converting to records. We have to beg project A to upgrade to Java 1X. And in
>> fact since they will likely not want to suddenly pull the rug out from all
>> their users on earlier Java versions, what I really need to beg them to do is
>> adopt jep238 multirelease jars, which probably also means adopting a
>> preprocessor in their build so they can generate the different versions (as
>> this is a pretty bad case for branching).

> Thought experiment: if you could wave a magic wand and retroactively re-target
> all the worlds annotations to include R_C, and all the frameworks to support
> it, would you still want this? In other words, is this a feature that you want
> in its own right, or just as a migration aid, right? (It has to be the latter,
> right?)
I have a question, how javac 8 works when it sees a MODULE as annotation target ? in my opinion, it should ignore it, no ? 

Rémi 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20190319/d6577f0c/attachment.html>