[Isolate-interest] Isolate equals(), hashCode(), toString()

[Curt Cox]

Doug,

In equals():

"The notion here is that these methods must intrinsically be overridden in
class Isolate, but they still obey class Object specs."

The current Isolate Javadoc says:

"Tests this Isolate for equality with the given object. Returns true if and
only if other is not null and denotes the same isolate as this."

I read "the same" as "x==y" and "equivalent" as "x.equals(y)".  So, "denotes
the same isolate as this" sounds to me like for an Isolate x and an Object
y, x.equals(y) if and only if x==y.  Perhaps this could be clarified by
something like:

"Tests this Isolate for equality with the given object. Returns true if and
only if other is not null and denotes the same isolate (although not
necessarily the identical Isolate object) as this.  In other words, the same
isolate need not always be represented by the same Isolate object."

It would also be useful to explain when identity semantics would be
difficult or impossible to achieve, since they would appear to be a natural
consequence of efficient implementation.

In toString(), the current Javadoc says:

"Returns an implementation-dependent string representation of this isolate.
It is guaranteed that if, for two isolates i1 and i2, !i1.equals(i2) then
!i1.toString().equals(i2.toString()).

The release notes describe the format of this string in this release."

Which I would change to:
 
"Returns an implementation-dependent string representation of this isolate.
It is guaranteed that if, for two isolates i1 and i2, !i1.equals(i2) then
!i1.toString().equals(i2.toString()).  In other words, two Isolates that are
not equivalent will always return StringS that are not equivalent.  Two
Isolates that are equivalent may return the same or different StringS.

The release notes describe the format of this string in this release."
 
And I'll still curious about whatever release notes are behind that broken
link.

- Curt