There needs to be a name for the phenomena where, when we have a wrong default (e.g., mutable method parameters), every time a new language context comes up where new code will be written, it seems overwhelmingly tempting to say “but surely we can flip the default for _them_.” (We saw the same thing with “lambda parameters should be implicitly final.”)
It’s always good to knock on this door, but most of the time the door is locked by the latch of either migration compatibility, or complexity management, or both. In this case (as with lambda parameters), I think it’s both. The more differences there are between a record and the equivalent boilerplate, the more pain users will have migrating between them. And a rule like this is an isolated fact that users have to carry around, rather than a general rule — increasing the complexity of the language semantics. I would love to get to “trust final fields” everywhere — that’s a rule that neither gets in the way of migration nor an isolated fact you have to keep track of separately. (In fact, its really just what you would expect.) So I share your goal, but I don’t think this is the train that goes there. > On Mar 7, 2019, at 10:51 PM, Remi Forax <fo...@univ-mlv.fr> wrote: > > As you may know, there are two kinds of final field in Java, > you have final fields and trusted final fields, the former are classical > final fields the later are final fields that can no be changed by reflection > thus are considered as "real" final field by JITs > (see https://shipilev.net/jvm/anatomy-quarks/17-trust-nonstatic-final-fields/ > for more). > > So should record fields always be trusted ? > > Rémi > > ----- Mail original ----- >> De: "Brian Goetz" <brian.go...@oracle.com> >> À: "amber-spec-experts" <amber-spec-experts@openjdk.java.net> >> Envoyé: Vendredi 1 Mars 2019 21:14:31 >> Objet: Updated document on data classes and sealed types > >> 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.
