On Mon, Jun 7, 2021 at 3:00 PM Dan Smith <daniel.sm...@oracle.com> wrote: > > > On Jun 7, 2021, at 9:13 AM, Dan Smith <daniel.sm...@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
