Making Object abstract

[Cay Horstmann]

There was discussion about applet removal where some people said "I have 
this perfectly good legacy program that I rely upon, which was written 
so that it could also run as an applet. I don't want to do that, but I 
do want it as an application. And I can't fix the source." Instead of 
removing Applet, it might be better to stub it out so that the "floor 
wax/desert topping" programs that are both applets and applications can 
still work.

Generally, it seems in the spirit of Java to keep on trucking. If so, It 
may be difficult to ever disallow "new Object()".

On the other hand, I write books explaining this stuff, and I do think 
it might help learners if Object was abstract. It's not easy to explain 
to beginners why you would ever instantiate Object. "So you can lock on 
it" doesn't win hearts and minds.

This is a cognitive dissonance I can live with. I am not bothered by 
potentially having to write in the future "Object is abstract but, 
unlike for all other abstract classes, new Object() works, with stern 
warnings, for old time's sake."

Cheers,

Cay


On 08/05/2021 20:01, Dan Smith wrote:
> 
> 
>> On May 8, 2021, at 9:50 AM, Dan Heidinga <heidinga at redhat.com> wrote:
>>
>> On Fri, May 7, 2021 at 9:34 PM Brian Goetz <brian.goetz at 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.
> 

-- 

Cay S. Horstmann | http://horstmann.com | mailto:cay at horstmann.com