[External] : Re: Making Object abstract

[Remi Forax]

> 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