IdentityObject and InlineObject

[Frederic Parain]

My two cents on this topic:

Looking back at our previous models, the “identity” marker and the “inline” marker
served two different and well identified purposes.

The “identity” marker signals that identity sensitive operations are allowed on a
given type. This is a marker we absolutely need somehow (the alternative to surround
all these operations with try { … } catch(IMSE e) … looks like a no-go).

The use case for an inline marker was to have the guarantee that a given type can
never be null, allowing developers to skip null checks in their code and write
null-free algorithms. In the old model, it was achieved by accepting only Q-types
which were guaranteed to be null-free.

But in the new model, this null-freeness cannot be guaranteed by the InlineObject
interface, because it is … an interface! There's no plan to make all sub-types of
InlineObject (including interfaces and abstract classes) null-free, and it sounds
like a terrible idea to try to enforce this kind of rules.

Bottom line: I think we've already lost the benefits of having an “inline type” marker,
so removing the “InlineObject” interface would simplify the model and would not have a
negative impact on what developers can do with the new user model.

Fred


> On Apr 8, 2020, at 12:54, Brian Goetz <brian.goetz at oracle.com> wrote:
> 
> This is a good time to review the motivations for Identity/InlineObject, and see if there's anything we want to tweak about it.  
> 
> There are two main branches of the motivation here: pedagogical and functional.  
> 
> Pedagogically, we're asking users to amend their view of "object" to allow for some objects to have identity, and some objects to not have identity, and supertypes are one of the prime ways we capture these sorts of divisions.  It's not an accident that we have both the informal statement "everything (except primitives) is an object" and the hierarchy constraint "all classes extend (implicitly or not) java.lang.Object".  Not only is Object a place to hang the behavior that is common to all objects (equality, etc), its position at the root of the hierarchy sends a message that conditions how we think about objects.  The intent of partitioning Object into IdentityObject and InlineObject is an attempt to capture the same.
> 
> Functionally, there are operations that apply only to identity objects, such as identity equality, synchronization, Object::wait, etc.  Some of these have been totalized appropriately (such as `==`); others are partial.  Having synchronization be partial, without offering developers a way to express "if I tried to synchronize on this thing, would it throw", just makes Java less reliable, so we want a way to express identity both in the dynamic type system (`instanceof IdentityObject`) and the static type system (`<T extends IdentityObject>`).  
> 
> We also thought, at one point in time, that InlineObject and IdentityObject would be a sensible place to put new methods or default implementations of Object methods.  However, as the design has evolved, the need for this has gone away.  This opens the door to a new possibility, which I'd like to evaluate: just         have one of them.  (And, if we only have one, the move is forced: IdentityObject.)  
> 
> In this world, we'd just have IdentityObject, which would be viewed as a refinement of Object -- "Object, with identity".  Identity classes would implement it implicitly, as today.  The pedagogy would then be, instead of "there are two disjoint kinds of Object", be "Some objects are enhanced with identity."  You'd still be able to say
> 
>     x instanceof IdentityObject
> 
> and
> 
>     void foo(IdentityObject o) { ... }
> 
> and
> 
>     class Foo<T extends IdentityObject> { ... }
> 
> as a way of detecting the refinement, but not the opposite.  So the questions are:
> 
>  - Pedagogically, does this help move users to the right mental model, or does the symmetric model do a better job?
>  - Functionally, is there anything we might do with InlineObject, that we would miss?  
> 
> Secondarily: 
> 
>  - If we take this step, is `IdentityObject` still the best name?
> 
>