Evolving instance creation

[Dan Smith]

One of the longstanding properties of class instance creation expressions ('new Foo()') is that the instance being produced is unique—that is, not '==' to any previously-created instance.

Value classes will disrupt this invariant, because it's possible to "create" an instance of a value class that already exists:

new Point(1, 2) == new Point(1, 2) // always true

A related, possibly-overlapping new Java feature idea (not concretely proposed, but something the language might want in the future) is the declaration of canonical factory methods in a class, which intentionally *don't* promise unique instances (for example, they might implement interning). These factories would be like constructors in that they wouldn't have a unique method name, but otherwise would behave like ad hoc static factory methods—take some arguments, use them to create/locate an appropriate instance, return it.

I want to focus here on the usage of class instance creation expressions, and how to approach changes to their semantics. This involves balancing the needs of programmers who depend on the unique instance invariant with those who don't care and would prefer fewer knobs/less complexity.

Here are three approaches that I could imagine pursuing:

(1) Value classes are a special case for 'new Foo()'

This is the plan of record: the unique instance invariant continues to hold for 'new Foo()' where Foo is an identity class, but if Foo is a value class, you might get an existing instance.

In bytecode, the translation of 'new Foo()' depends on the kind of class (as determined at compile time). Identity class creation continues to be implemented via 'new Foo; dup; invokespecial Foo.<init>()V'. Value class creation occurs via 'invokestatic Foo.<newvalue>()LFoo;' (method name bikeshedding tk). There is no compatibility between the two (e.g., if an identity class becomes a value class).

In a way, it shouldn't be surprising that a value class doesn't guarantee unique instances, because uniqueness is closely tied to identity. So special-casing 'new Foo()' isn't that different from special-casing Object.equals'—in the absence of identity, we'll do something reasonable, but not quite the same.

Factories don't enter into this story at all. If we end up having unnamed factories in the future, they will be declared and invoked with a separate syntax, and will be declarable both by identity classes and value classes. (Value class factories don't seem particularly compelling, but they could, say, be used to smooth migration, like 'Integer.valueOf'.)

Biggest concerns: for now, it can be surprising that 'new' doesn't always give you a unique instance. In a future with factories, navigating between the 'new' syntax and the factory invocation syntax may be burdensome, with style wars about which approach is better.

(2) 'new Foo()' as a general-purpose creation tool

In this approach, 'new Foo()' is the use-site syntax for *both* factory and constructor invocation. Factories and constructors live in the same overload resolution "namespace", and all will be considered by the use site.

In bytecode, the preferred translation of 'new Foo()' is 'invokestatic Foo.<new>()LFoo;'. Note that this is the case for both value classes *and identity classes*. For compatibility, 'new/dup/<init>' also needs to be supported for now; eventually, it might be deprecated. Refactoring between constructors and factories is generally compatible.

Because this re-interpretation of 'new Foo()' supports factories, there is no unique instance invariant. At best, particular classes can document that they produce unique instances, and clients who need this behavior should ensure they're working with classes that promise it. (It's not as simple as looking for a *current* factory, because constructors can be refactored to factories.)

For developers who don't care about unique instances, this is the simplest approach: whenever you want an instance of Foo, you say 'new Foo()'.

Biggest concerns: we've demoted an ironclad semantic guarantee to an optional property of some classes. For those developers/use cases who care about the unique instance invariant, that may be difficult, especially because we're undoing a longstanding property rather than designing it this way from the beginning.

(3) 'new Foo()' for unique instances and just 'Foo()' otherwise

Here, the 'new' keyword is reserved for cases in which a unique instance is guaranteed. For value class creation, factory invocation, and constructor invocation when unique instances don't matter, a bare 'Foo()' call is used instead. 'new Point()' would be an error—this syntax doesn't work with value classes.

In bytecode, 'new Foo()' always compiles to 'new/dup/<init>', while plain 'Foo()' typically compiles to 'invokestatic Foo.<make>()LFoo;' (method name bikeshedding tk). For compatibility, plain 'Foo()' would support 'new/dup/<init>' invocations as well, if that's all the class provides. Refactoring between constructors and factories is generally compatible for plain 'Foo()' use sites, but not 'new Foo()' use sites.

The plain 'Foo()' would become the preferred style for general-purpose usage, while 'new Foo()' would (eventually, after a long migration period) signal an interest in the unique instance guarantee. Java code written with the updated style is a little lighter on "ceremony".

Biggest concerns: a somewhat arbitrary shift in coding style for all programmers to learn, which at a minimum must be adopted when working with value classes.

---

What are your thoughts about the significance of the unique instance invariant? Is it important enough to design instance creation syntax around it? Do either (2) or (3) above sound like a better destination than the plan of record?