On May 8, 2019, at 12:31 PM, Dan Smith <daniel.sm...@oracle.com> wrote:
>
> I'm working on the introductory spec material, and have also come to this
> conclusion. All values are either *primitives* or *references*. Everything
> we've done in L-world has to do with refining the space of things that
> references can point to (*objects*).
>
>> ...
>
> Here's a cut of JVMS 2.4 that incorporates some of this terminology (some of
> it I've avoided, either because I didn't need it, or it seemed insufficiently
> precise.)
>
> I also decided to call out the `Object` type as a unique entity. This
> probably have some ripple effects elsewhere, which I haven't explored yet.
>
> It's hard to say much about identity without talking about
> acmp/substitutability; I chose the term "identical" here for that purpose
> (rather than the overloaded "equal").
When the current JLS and JVMS must talk about object identity
(identicality??) they tend to use the term "same". It's such a
humble word it's easy to miss. Maybe the latinate term
"identical" is better, although it's confusingly similar to "identity".
What you've written reads very well, and I have no suggestion
for improving it, except that the stuff about "nullable" and
"null-free" will shortly be false, when we introduce inline
classes that encode null natively (as a combination of their
field values).
I did a careful search in the JVMS and JLS for the word "same"
and found these uses where "identical" could be a candidate
for replacing or clarifying "same":
> JVMS 5.4.3 Resolution
> Subsequent attempts to resolve the symbolic reference always succeed
> trivially and result in the same entity produced by the initial resolution.
> [condy may resolve to an inline instance]
> JLS 4.3.1 Objects
> There may be many references to the same object.
> Most objects have state, stored in the fields of objects that are instances of
> classes or in the variables that are the components of an array object.
> If two variables contain references to the same object, the state of the
> object
> can be modified using one variable's reference to the object, and then the
> altered state can be observed through the reference in the other variable.
> …
> Example 4.3.1-2. Primitive and Reference Identity
> …
> Each object is associated with a monitor ([17.1]), which is used by
> `synchronized` methods ([8.4.3]) and the `synchronized` statement ([14.19]) to
> provide control over concurrent access to state by multiple threads ([17]).
> JLS 4.12.4 `final` Variables
> Once a `final` variable has been assigned, it always contains the same value.
> If a `final` variable holds a reference to an object, then the state of the
> object may be changed by operations on the object, but the variable will
> always
> refer to the same object.
> This applies also to arrays, because arrays are objects; if a `final` variable
> holds a reference to an array, then the components of the array may be changed
> by operations on the array, but the variable will always refer to the same
> array.
>
> JLS Example 8.3.1.1-1. `static` Fields
> These two ways of accessing the `origin` class variable access the same
> object,
> evidenced by the fact that the value of the reference equality expression
> ([15.21.3])
> JLS Example 8.8.7.1-2. Qualified Superclass Constructor Invocation
> Perhaps surprisingly, the same instance of `Outer` may serve as the
> immediately
> enclosing instance of `ChildOfInner` with respect to `Inner` *for multiple
> instances of `ChildOfInner`*. [careful outers could be inline objects]
> JLS Example 10.7-2. Shared Subarrays After A Clone
> showing that the `int[]` array that is `ia[0]` and the `int[]` array that is
> `ja[0]` are the same array. [seems OK here]
> JLS 14.11 The `switch` Statement {#jls-14.11}
> - No two of the `case` constants associated with the `switch` statement have
> the same value. [can be java.lang.String references!]
> JLS 14.19 The `synchronized` Statement
> Acquiring the lock associated with an object does not in itself prevent other
> threads from accessing fields of the object or invoking un-`synchronized`
> methods on the object. [may need to be restricted to identity objects]
> JLS Example 15.8.3-1. The `this` Expression
> If the other vector is the same vector object as the one for which the
> `equals`
> method was invoked, then the check can skip the length and value comparisons.
> [seems OK here]
> JLS 15.21.3 Reference Equality Operators `==` and `!=`
> At run time, the result of `==` is `true` if the operand values are both
> `null`
> or both refer to the same object or array; otherwise, the result is `false`.
> …
> The result of `!=` is `false` if the operand values are both `null` or both
> refer to the same object or array; otherwise, the result is `true`.
Also watch out for the phrase "same monitor". It's safe if used
carefully, but it tends to go along with the assumption that objects
and monitors are in one-to-one correspondence, which is not
true for inline objects.
The following section might need to be reformulated or rescoped,
if static factory methods named <init> are classified as I.I.M.s:
> JVMS 4.10.2.4 Instance Initialization Methods and Newly Created Objects
> When an instance initialization method is invoked on a class instance, only
> those occurrences of the special type on the operand stack or in the local
> variable array that are the same object as the class instance are replaced.
The language about arrays is good. When the dust settles, we might
want to talk about making *some* arrays of existing array types,
or *new array types*, marry the semantics of arrays to those of inline
objects. This would be one approach to frozen arrays.
— John
