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