[External] : Re: Making Object abstract

[Brian Goetz]

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

I agree that if we were starting from scratch, making Object abstract 
would be the sensible choice.  But there's just sooooooo much code that 
does at least one `new Object()` at the source level, and this seems a 
questionable place to spend our incompatibility budget.  We don't want 
people's first experience of Valhalla -- before they even know what it 
is -- to be "nothing compiles anymore."  That's a way to get started on 
the wrong foot.

We can certainly discourage it by warning ("please use 
Object.newInstance() instead"), and start the migration early (we can 
start by adding Object::newInstance now, and add to the set of 
pre-valhalla optional warnings), but it seems like too big a leap to 
start erroring on `new Object()` immediately.

> Continuing to allow `new Object()` at the source level will encourage
> puzzlers and confusion as expressions like this will be false only for
> Object:
> ```
> new Object().getClass() == Object.class
> ```
> Isn't it better to make this illegal at the source level so the code
> says what it means?
>
> My (non-exhaustive) examination of uses of `new Object()` in code
> bases I've looked at (which is a small, jvm-centric set of uses) tend
> to fall into two buckets:
> * tests generating objects to validate GCs occur, metrics report
> additional allocations or free space correctly.  None of these cases
> care about the Object itself.  It's just something to occupy heap
> space.
> * allocating a unique object to use as a lock
>
> Is there some other pattern that suggests keeping `new Object()` at
> the source level is worth the special cases in the model?
>
> --Dan
Most cases are the lock.  And while Joe Java doesn't write this that 
often, nearly every library has this once or twice.

So, I agree on the goal, I guess I don't think we can get there in one 
go without avoidably burning some goodwill.