Records and annotations

[Brian Goetz]

>
>      - 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?)


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20190318/0ea27b43/attachment.html>