> On May 8, 2021, at 9:50 AM, Dan Heidinga <heidi...@redhat.com> wrote: > > On Fri, May 7, 2021 at 9:34 PM Brian Goetz <brian.go...@oracle.com> 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 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 model as suggested by Dan Smith and allows > making Object abstract.
One way or another, we've got a migration problem—we want people to update their code to use a new idiom. This could look like: - With Primitive Objects, introduce an alternative API point & javac warnings. After a few versions, maybe drop support for the constructor call. - Before Primitive Objects, introduce an alternative API point & javac warnings. With Primitive Objects (final), make the constructor call illegal. There needs to be some sort of gradual pathway—can't just spring it on people when Primitive Objects are final. We did the latter with the primitive wrappers, but in that case the deprecation began in 9 (2017), and I think 'new Integer' is a more rare occurrence than 'new Object'. Not sure we could squeeze it in before Primitive Objects are final. (But if we want to, we'd better get moving on it!) I see the question of whether Object is abstract as orthogonal: unless we remove support for 'new Object' before the change, we're going to have a period where 'new Object()' is special, and not necessarily subject to the "can't instantiate an abstract class" rule.
