[External] : Re: Making Object abstract

[Dan Heidinga]

On Mon, Jun 7, 2021 at 3:00 PM Dan Smith <daniel.smith at oracle.com> wrote:
>
> > On Jun 7, 2021, at 9:13 AM, Dan Smith <daniel.smith at oracle.com> 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 migration in 17, or wait another release or two. What's the rush?
>
> Just to clarify this, because I know, when it comes to compatibility impact, adoption patterns will tend to have quantum leaps between LTS releases—from 11 to 17 to 26. It's potentially meaningful that "17" is a number in that set.

Right.  "17" is a meaningful number in that set, especially if we see
the possibility that "new Object();" becomes illegal by "26".  Having
a nice landing pad to ease migration of libraries in 17 sets us up for
easy adoption by libraries.  And it provides clear guidance for them
to target.

>
> However: in some future day (when we're all running Java in our self-driving electric cars), we will decide the time has come to turn 'new Object()' from a warning into an error. At that point, we will want to consider the body of source code that plans to compile with --release NN (NN >> 26), and how much of that source code still has lingering 'new Object()' uses. This universe of source code i) is comfortable with all the Valhalla features, and ii) does not intend to run on any pre-NN JVMs. Where there are a few lingering 'new Object()' uses, presumably there will be tooling in place to quickly fix them up.
>
> Meanwhile, there's no impact in Java NN on legacy binaries (the JVM will indefinitely support 'new java/lang/Object'), and there's no impact on sources compiled with --release 17 or --release 26, etc.

I'd hope that NN >> 26 isn't required to get the ecosystem to jump.
If we don't start the ball rolling, then it'll definitely be that much
longer to change.

>
> I hope NN is a relatively small number, but... shrug. We'll get there when we get there. There are no downstream dependencies.
>
> Nor do I expect an API point available in 17 to hasten this much, because there won't be any *push* to change source code until JEP 401 comes along with a warning about 'new Object()'.
>

Sure javac might not warn now but if it starts to warn in 17 < version
< 26 then even libraries still targeting 17 can "do the right thing".

--Dan