[External] : Re: Making Object abstract

[Dan Heidinga]

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.

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


> On 5/7/2021 9:06 PM, Dan Heidinga wrote:
>
> I would strongly discourage new developers from saying "new Object()", and I think javac/IDEs should warn about it. It's allowed purely for compatibility. If developers insist on using it, then whether we've decreed that Object is abstract or not, they're going to need to learn that "new Object()" is a special case that doesn't behave the way they expect "new Foo()" to behave.
>
> I had assumed that we were making `new Object()` illegal syntax when
> the Primitive Classes jep landed.  We need to keep the bytecode
> sequence working for legacy classfiles but don't need the language to
> support writing it in the future.  Was that incorrect?
>
> There was also a proposal to add a Object::newObject() helper method
> as a replacement for using `new Object()` which may be why I assumed
> the old syntax would be illegal in the future.
>
> --Dan
>
>