On Sat, Mar 9, 2019 at 4:47 AM Brian Goetz <brian.go...@oracle.com> wrote:
This came up before, but we didn’t reach a conclusion. > > A record component is more than just the lower-level members (fields, > accessors, ctor params) it gets desugared too. So it seems reasonable that > it be considered an annotatable program element, and that reflection expose > directly the annotations on record components (separately from any > annotations on the class members that may or may not derive from desugaring > of records.) > > But, that still leaves the question of whether the desugaring should, or > should not be, transparent to annotations. My sense is that pushing > annotations down to fields, ctor params, and accessors _seems_ friendly, > but also opens a number of uncomfortable questions. > > - 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. - What if @A has a target set of { field, parameter }, but for some reason > the user does _not_ want the annotation pushed down? Tough luck? > Redeclare the member without the annotation? > Sure, that sounds fine. > - If the user explicitly redeclares the member (ctor, accessor), what > happens? Do we still implicitly push down annotations from record > components to the explicit member? Will this be confusing when the source > says “@B int x() -> x”, but reflection yields both @A and @B as annotations > on x()? > Saying that redeclaring makes you responsible for the annotation choices (i.e., none copied) makes perfect sense to me! 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). This can result in a long period where records are unadoptable by the end user. Btw, this precise issue will not be hypothetical for us. :-) My gut sense is that the stable solution is to make record component a new > kind of target, and encourage frameworks to learn about these, rather than > trying to fake out frameworks by emulating legacy behavior. > > > On Mar 8, 2019, at 8:43 PM, Kevin Bourrillion <kev...@google.com> wrote: > > Re: annotations, > > Doc says, "Record components constitute a new place to put annotations; > we'll likely want to extend the @Target meta-annotation to reflect this." > > I'm sure we discussed this before, but I also expect to be able to put any > METHOD-, FIELD- or PARAMETER-targeted annotation on a record component, and > have that annotation appear to be present on the synthesized > accessor/field/constructor-parameter. Is that sensible? > > (As for records themselves, I expect they are targeted with TYPE just as > enums/interfaces/"plain old classes" (jeesh, is there any term that means > the latter?).) > > > > > > > > On Fri, Mar 1, 2019 at 12:16 PM Brian Goetz <brian.go...@oracle.com> > wrote: > >> I've updated the document on data classes here: >> >> http://cr.openjdk.java.net/~briangoetz/amber/datum.html >> >> (older versions of the document are retained in the same directory for >> historical comparison.) >> >> While the previous version was mostly about tradeoffs, this version >> takes a much more opinionated interpretation of the feature, offering >> more examples of use cases of where it is intended to be used (and not >> used). Many of the "under consideration" flexibilities (extension, >> mutability, additional fields) have collapsed to their more restrictive >> form; while some people will be disappointed because it doesn't solve >> the worst of their boilerplate problems, our conclusion is: records are >> a powerful feature, but they're not necessarily the delivery vehicle for >> easing all the (often self-inflicted) pain of JavaBeans. We can >> continue to explore relief for these situations too as separate >> features, but trying to be all things to all classes has delayed the >> records train long enough, and I'm convince they're separate problems >> that want separate solutions. Time to let the records train roll. >> >> I've also combined the information on sealed types in this document, as >> the two are so tightly related. >> >> Comments welcome. >> > > > -- > Kevin Bourrillion | Java Librarian | Google, Inc. | kev...@google.com > > > -- Kevin Bourrillion | Java Librarian | Google, Inc. | kev...@google.com