> De: "Brian Goetz" <brian.go...@oracle.com> > À: "Kevin Bourrillion" <kev...@google.com> > Cc: "amber-spec-experts" <amber-spec-experts@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
