[External] : Re: Making Object abstract
Remi Forax
forax at univ-mlv.fr
Sat Jun 5 15:33:59 UTC 2021
> De: "Brian Goetz" <brian.goetz at oracle.com>
> À: "Dan Heidinga" <heidinga at redhat.com>
> Cc: "daniel smith" <daniel.smith at oracle.com>, "valhalla-spec-experts"
> <valhalla-spec-experts at 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
More information about the valhalla-spec-observers
mailing list