> De: "Brian Goetz" <brian.go...@oracle.com> > À: "Dan Heidinga" <heidi...@redhat.com> > Cc: "daniel smith" <daniel.sm...@oracle.com>, "valhalla-spec-experts" > <valhalla-spec-experts@openjdk.java.net> > Envoyé: Samedi 5 Juin 2021 17:21:11 > Objet: Re: [External] : Re: Making Object abstract
> Rampdown is next week; time is fleeting. > I think the path of adding Objects::newIdentity in 17 seems the best > alternative. If there are objections, make them now. no objection, quite the opposite, i agree with Dan H analysis. Rémi > On 6/4/2021 4:10 PM, Dan Heidinga wrote: >> Quoting from several previous emails in this thread: >> Brian said: >>> I agree that we can introduce the new API point immediately. The 17 window >>> hasn't even closed yet! But we'd have to get a move on. But >>> realistically, we >>> can expect it to be several years before we are comfortable erroring on the >>> `new Object()` constructor. >> Dan S. responded: >>> Of course these details can evolve, but as it stands, there's not a good >>> path to >>> introducing the API before we introduce primitive objects—IdentityObject >>> has no >>> reason to exist without primitive objects. So efforts to get people to >>> migrate >>> to something new will need to wait until then. (As discussed earlier in the >>> thread, that's fine—we're inevitably going to have a period of time when >>> 'new >>> Object()' does something weird.) >> And Brian proposes: >>> What I like about the Objects placement (thought took me a while to come >>> around to this) is that it fits into the other Objects operations, in >>> that they are all sugar for code we could write without help. I don't >>> think we need or want a canonical "class of all anonymous identity >>> objects" type. >> This gives us a pretty reasonable story for where to put a minimal >> helper API today, before the window for 17 closes. Even taking the >> "several years before we are comfortable erroring" into account, it >> would help the ecosystem migrate to Valhalla if we get the replacement >> API into the upcoming LTS so the adoption is higher before we start >> erroring on it. >> We know - for better or for worse - that many applications leap from >> LTS to LTS which requires library authors to support previous LTS >> releases while adding support for current release. And that apps >> can't leap faster than their dependencies so we want to smooth the >> path that lets applications track the release cadence. >> This Objects::newIdentity api seems like an easy one to add today that >> we can point libraries at it as they adopt 17. I don't see much risk >> that Valhalla will change in a way that invalidates this api. >> Wouldn't it be better to lay that foundation now, before 17 ships, >> then to wait? >> --Dan
