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 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.

Reply via email to