On Jun 17, 2021, at 4:40 AM, Remi Forax
mailto:fo...@univ-mlv.fr>> wrote:
As a stretch move, I think we can even retro-upgrade
the type checking of Objects::newIdentity with type
variable trickery, when IdentityObject becomes real.
Please see:
https://bugs.openjdk.java.net/secure/attachment/951
- Mail original -
> De: "John Rose"
> À: "Brian Goetz"
> Cc: "daniel smith" , "valhalla-spec-experts"
>
> Envoyé: Mercredi 16 Juin 2021 23:50:35
> Objet: Re: Making Object abstract
> On Jun 2, 2021, at 7:57 AM, Brian Goetz
On Jun 2, 2021, at 7:57 AM, Brian Goetz wrote:
>
> A minor bikeshed comment: We're asking users to change their `new Object()`
> to `IdentityObject.newIdentity()`, and they may ask "why do I have to say
> 'Identity' twice"? (And by ask, I mean grumble, because we're already asking
> them to c
Sorry for the delayed response to this, I've gone back and forth on
whether it's worth pushing on this helper method or not and still
think it is.
>
> For comparison, the wrapper class constructors first got warnings in 9
> (2017), and can probably expect to get errors by 23 (2024). So, nah, I do
> On Jun 7, 2021, at 2:46 PM, Dan Heidinga wrote:
>
> On Mon, Jun 7, 2021 at 3:00 PM Dan Smith wrote:
>>
>>> On Jun 7, 2021, at 9:13 AM, Dan Smith wrote:
>>>
>>> On the other side, I'm not that persuaded by the argument for urgency. We
>>> want to encourage a slow migration from 'new Object
On Mon, Jun 7, 2021 at 3:00 PM Dan Smith wrote:
>
> > On Jun 7, 2021, at 9:13 AM, Dan Smith wrote:
> >
> > On the other side, I'm not that persuaded by the argument for urgency. We
> > want to encourage a slow migration from 'new Object()' to
> > 'SomeClass.newIdentity()'. It's not going to be
> On Jun 7, 2021, at 9:13 AM, Dan Smith wrote:
>
> On the other side, I'm not that persuaded by the argument for urgency. We
> want to encourage a slow migration from 'new Object()' to
> 'SomeClass.newIdentity()'. It's not going to be completed for a number of
> years. We can start that migrat
On 6/7/2021 11:13 AM, Dan Smith wrote:
On Jun 5, 2021, at 9:21 AM, Brian Goetz wrote:
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.
I still think that's a second-best opti
> On Jun 5, 2021, at 9:21 AM, Brian Goetz wrote:
>
> 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.
I still think that's a second-best option. Utility classes were all t
> De: "Brian Goetz"
> À: "Dan Heidinga"
> Cc: "daniel smith" , "valhalla-spec-experts"
>
> Envoyé: Samedi 5 Juin 2021 17:21:11
> Objet: Re: [External] : Re: Making Object abstract
> Rampdown is next week; time is fleeting.
> I th
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.
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 i
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
After a few minutes of thought, I think it might be a better fit to put this at
Objects::newIdentity. The methods in Objects are conveniences that users could
write themselves, which this basically is -- there's nothing special about this
method, other than having a preferred alternative t
> On Jun 2, 2021, at 8:57 AM, Brian Goetz wrote:
>
> A minor bikeshed comment: We're asking users to change their `new Object()`
> to `IdentityObject.newIdentity()`, and they may ask "why do I have to say
> 'Identity' twice"? (And by ask, I mean grumble, because we're already asking
> them
A minor bikeshed comment: We're asking users to change their `new
Object()` to `IdentityObject.newIdentity()`, and they may ask "why do I
have to say 'Identity' twice"? (And by ask, I mean grumble, because
we're already asking them to change their working code.)
After a few minutes of thought
> On May 8, 2021, at 1:20 PM, Brian Goetz wrote:
>
> 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 `ne
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.
One way or another, we've got a
> On May 8, 2021, at 9:50 AM, Dan Heidinga wrote:
>
> On Fri, May 7, 2021 at 9:34 PM Brian Goetz wrote:
>>
>> From a compatibility perspective, we can't outlaw either `new Object()` or
>> `new j/l/Object`, but we can (a) add Object::newInstance and (b) warn on
>> recompilation to switch to
We're in complete agreement on needing to support it at the bytecode
level. The part I'm unclear on is why that requires continuing to
allow `new Object()` at the source level. Removing it is, of course,
a source incompatible change with all its attendant pain, but it
results in the simpler
On Fri, May 7, 2021 at 9:34 PM Brian Goetz wrote:
>
> From a compatibility perspective, we can't outlaw either `new Object()` or
> `new j/l/Object`, but we can (a) add Object::newInstance and (b) warn on
> recompilation to switch to `Object::newInstance`.
>
We're in complete agreement on needin
From a compatibility perspective, we can't outlaw either `new Object()`
or `new j/l/Object`, but we can (a) add Object::newInstance and (b) warn
on recompilation to switch to `Object::newInstance`.
On 5/7/2021 9:06 PM, Dan Heidinga wrote:
I would strongly discourage new developers from saying
> I would strongly discourage new developers from saying "new Object()", and I
> think javac/IDEs should warn about it. It's allowed purely for compatibility.
> If developers insist on using it, then whether we've decreed that Object is
> abstract or not, they're going to need to learn that "new
> On May 7, 2021, at 4:38 PM, Brian Goetz wrote:
>
> I think the question is: "cleaner for whom." The parenthetical remarks
> "except for Object" are mostly our mess to corral; "new Object()" working,
> even when Object is seen to be abstract, will be extremely confusing for new
> developers
I think the question is: "cleaner for whom." The parenthetical remarks
"except for Object" are mostly our mess to corral; "new Object()"
working, even when Object is seen to be abstract, will be extremely
confusing for new developers learning what abstract means. It's not
just that reflection
24 matches
Mail list logo
