Alternative to IdentityObject & ValueObject interfaces

[Brian Goetz]

Thanks Dan for putting the work in to provide a credible alternative.

Let me add some background for how we came up with these things.  At 
some point we asked ourselves, what if we had identity and value classes 
from day 1?  How would that affect the object model?  And we concluded 
at the time that we probably wouldn't want the identity-indeterminacy of 
Object, but instead would want something like

     abstract class Object
     class IdentityObject extends Object { }
     abstract class ValueObject extends Object { }

So the {Identity,Value}Object interfaces seemed valuable pedagogically, 
in that they make the object hierarchy reflect the language division.  
At the time, we imagined there might be methods that apply to all value 
objects, that could live in ValueObject.

A separate factor is that we were taking operations that were previously 
total (locking, weak refs) and making them partial. This is scary!  So 
we wanted a way to make these expressible in the static type system.

Unfortunately, the interfaces do not really deliver on either goal, 
because we can't turn back time.  We still have to deal with `new 
Object()`, so we can't (yet) make Object abstract. Many signatures will 
not be changeable from "Object" to "IdentityObject" for reasons of 
compatibility, unless we make IdentityObject erase to Object (which has 
its own problems.)  If people use it at all for type bounds, we'll see 
lots of uses of `Foo<? extends Bar&IdentityObject>`, which will put more 
pressure on our weak support for intersection types.  And dynamic errors 
will still happen, because too much of the world was built using 
signatures that don't express identity-ness. (Kevin will see a parallel 
to introducing nullness annotations; it might be fine if you build the 
world that way from scratch, but the transition is painful when you have 
to interpret an unadorned type as "of unspecified identity-ness.")

Several years on, we're still leaning on the same few motivating 
examples -- capturing things like "I might lock this" in the type 
system.  That we haven't come up with more killer examples is notable.  
And I grow increasingly skeptical of the value of the locking example, 
both because this is not how concurrent code is written, and because we 
*still* have to deal with the risk of dynamic errors because most of the 
world's code has not been (and will not be) written to use 
IdentityObject throughout.


As Dan points out, the main thing we give up by backing off from these 
interfaces is the static typing; we don't get to use `IdentityObject` as 
a parameter type, return type, or type bound.  And the only reason we've 
come up with so far to want that is a pretty lame one -- locking.

 From a language design perspective, I find that you declare a class 
with `value class`, but you express the subclassing constraint with 
`extends IdentityObject`, to be pretty leaky.

On 3/22/2022 7:56 PM, Dan Smith wrote:
> In response to some encouragement from Remi, John, and others, I've decided to take a closer look at how we might approach the categorization of value and identity classes without relying on the IdentityObject and ValueObject interfaces.
>
> (For background, see the thread "The interfaces IdentityObject and ValueObject must die" in January.)
>
> These interfaces have found a number of different uses (enumerated below), while mostly leaning on the existing functionality of interfaces, so there's a pretty good complexity vs. benefit trade-off. But their use has some rough edges, and inserting them everywhere has a nontrivial compatibility impact. Can we do better?
>
> Language proposal:
>
> - A "value class" is any class whose instances are all value objects. An "identity class" is any class whose instances are all identity objects. Abstract classes can be value classes or identity classes, or neither. Interfaces can be "value interfaces" or "identity interfaces", or neither.
>
> - A class/interface can be designated a value class with the 'value' modifier.
>
> value class Foo {}
> abstract value class Bar {}
> value interface Baz {}
> value record Rec(int x) {}
>
> A class/interface can be designated an identity class with the 'identity' modifier.
>
> identity class Foo {}
> abstract identity class Bar {}
> identity interface Baz {}
> identity record Rec(int x) {}
>
> - Concrete classes with neither modifier are implicitly 'identity'; abstract classes with neither modifier, but with certain identity-dependent features (instance fields, initializers, synchronized methods, ...) are implicitly 'identity' (possibly with a warning). Other abstract classes and interfaces are fine being neither (thus supporting both kinds of subclasses).
>
> - The properties are inherited: if you extend a value class/interface, you are a value/class interface. (Same for identity classes/interfaces.) It's an error to be both.
>
> - The usual restrictions apply to value classes, both concrete and abstract; and also to "neither" abstract classes, if they haven't been implicitly made 'identity'.
>
> - An API ('Object.isValueObject()'?) allows for dynamically distinguishing between value objects and identity objects. The reflection API (in java.lang.Class) allows for detection of value classes/interfaces, identity classes/interfaces, and "neither" classes/interfaces.
>
> - TBD whether/how we track these properties statically so that the type system catch mismatches between non-identity class types and uses that assume identity.
>
> JVM proposal:
>
> - Same conceptual framework.
>
> - Classes can be ACC_VALUE, ACC_IDENTITY, or neither.
>
> - Legacy-version classes are implicitly ACC_IDENTITY. Legacy interfaces are not. Optionally, modern-version concrete classes are also implicitly ACC_IDENTITY.
>
> (Trying out this alternative approach to abstract classes: there's no more ACC_PERMITS_VALUE; instead, legacy-version abstract classes are automatically ACC_IDENTITY, and modern-version abstract classes permit value subclasses unless they opt out with ACC_IDENTITY. It's the bytecode generator's responsibility to set these flags appropriately. Conceptually cleaner, maybe too risky...)
>
> - At class load time, we inherit value/identity-ness and check for conflicts. It's okay to have neither flag set but inherit the property from one of your supers. We also enforce constraints on value classes and "neither" abstract classes.
>
> ---
>
> So how does this score as a replacement for the list of features enabled by the interfaces?
>
> - Dynamic detection: 'obj instanceof ValueObject' is quite straightforward; if we can replace that with 'obj.isValueObject()', that feels about equally useful. (I'd be more pessimistic about something like 'Objects.isValueObject(obj)'.)
>
> - Subclass restriction: 'implements IdentityObject' has been replaced with the 'identity' modifier. Complexity cost of special modifiers seems on par with the complexity of special rules for inferring and checking the superinterfaces. I think it's a win that we use the 'value' modifier and "value" terminology for all kinds of classes/interfaces, not just concrete classes.
>
> - Variable types: I don't see a good way to get the equivalent of an 'IdentityObject' type. It would involve tracking the 'identity' property through the whole type system, which seems like a huge burden for the occasional "I'm not sure you can lock on that" error message. So we'd probably need to be okay letting that go. Fortunately, I'm not sure it's a great loss—lots of code today seems happy using 'Object' when it means, informally, "object that I've created for the sole purpose of locking".
>
> - Type variable bounds: this one seems more achievable, by using the 'value' and 'identity' keywords to indicate a new kind of bounds check ('<identity T extends Runnable>'). Again, it's added complexity, but it's more localized. We should think more about the use cases, and decide if it passes the cost/benefit analysis. If not, nothing else depends on this, so it could be dropped. (Or left to a future, more general feature?)
>
> - Documentation: we've lost the handy javadoc location to put some explanations about identity & value objects in a place that curious programmers can easily stumble on. Anything we want to say needs to go in JLS/JVMS (or perhaps the java.lang.Object javadoc).
>
> - Compatibility: pretty clear win here. No interface injection means tools that depend on reflection results won't be broken. (We've found a significant number of these problems in our own code/tests, FWIW.) No new static types means inference results won't change. There's less risk of incompatibilities when adding/removing the 'identity' and 'value' keywords (although there can still be source, binary, and behavioral incompatibilities).
>