[External] : Re: Making Object abstract

[Dan Heidinga]

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 don't see cramming that into a 3-year cycle. More like warnings in ~23 (2024), errors in ~35 (2030). (Even if we have an API point in 17, I don't think we'd anticipate any warnings until JEP 401 is finalized.)
>
> >> 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".
>
> Here's the thing though: if you compile with '--release 17', you're not going to get any warnings. You'll get class files that still do 'new java/lang/Object', but these will be future-proof—none of this is a binary problem. Once we turn on the warnings, by '--release 23', we'll definitely have an alternative API point to use. And javac can generate bytecode that uses it, whether you use the "right syntax" or not. We'll gently encourage you to update your sources, and then eventually, for '--release 35' or whatever, report an error.
>

Dan, you may be right about the timeline but I see this helper method
as a nudge to the community that says "we want migration to Valhalla
to be easy and we'll give you the tools to prepare as early as we
can".  By not adding it now, we're limiting our opportunity to move
earlier if we see sufficient adoption / change in usage.  Not adding
it makes the timeline above a self-fulfilling prediction.

Will we end up on your suggested timeline?  Maybe.  But I'd still
rather lay the groundwork to be somewhere better.

--Dan