[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Ozone object identity...
I am back. Got side track to do some Waba hacking. Waba is a Java VM
implementation for small device like Palm or Pocket PC. There will be
some relevance with the object identity we are discussing here later on.
> > Using default equals and hashCode may not be such a good idea since
> > there may be need in application to override those two methods.
>
> On the other hand it's a very good idea since it allows to handle the
> persistent object identity of ozone the same way as the identity of transient
> objects. For transient objects you can easily determine if two object are the
> same but you can _not_ access the pointer/id/reference/whatever-it-is-in-Java
> directly. The proxies of ozone act the same way.
>
Well... This is getting philosophical but here we go.
According to the formalism of Object Oriented Programming, each object
has identity, state and behavior. Identity is unique for each object.
For Java transient objects, the identity is the "object pointer" and the
equality of two object should be determined by the '==' operator. For
example,
MyObject objOne = new MyObject();
MyObject objTwo = new MyObject();
These are two objects with two unique identity.
The equals() operator should mean equivlent. It means that two object
have the same states. The following is a quote from the api doc of
java.lang.Object.
"The equals method implements an equivalence relation"
Being "equals()" does not mean that two object are identical. It just
mean the two object has the same state.
The hasCode() according to the api doc doesn't really imply anything on
an object's identity or equivelance. It's simply, as implied by its
name, a hashCode. We can have the following situation and it's perfectly
legal.
objOne.hasCode() == objTwo.hasCode() ----> TRUE
objOne.equals(objTwo) ----> FALSE
objOne == objTwo ----> FALSE
For transient Java object, we do have access its object pointer. The
pointer being the one assigned to the object variable and the only
operation available for us is ==. The default hasCode() of
java.lang.Object is a native method and it retrive the memory address of
the allocated object. In sense, this is the object id to the particular
object.
If we can accept the above notion on object id, equals() and hasCode(),
the current implementation of Ozone doesn't give an object its identity
and an identity is the most important value of an object in a OO world.
> Anyway, sometimes you have to change the behaviour of hashCode/equals, which
> then breaks this model. What about a identityHashCode() method?
>
> Also, David, what do you want to return from a getObjectIdentity() method? The
> internal object ID? This would make client code depend on the internal
> implementation! (the current 64bit number is one solution maybe we have to
> change this for some reasons in the future)
>
My idea is to return a String repreenting the Object ID. My current
thinking is to use an URI to represent the object id. This idea is
largely influence by the RDF and Semantic Web
(http://www.w3.org/2001/sw/). The idea is to make each ozone object
universal on Internet.
The format of the URL will be roughly look like the following:
ozonedb:remote://ozone.d11e.com:3333/com.d11e.MyObject/1.0/1234/5678
It's divided into the following parts:
1. Server ID: ozonedb:remote://ozone.d11e.com:3333
This is to locate the server on the Internet.
2. Class name: com.d11e.MyObject
The Class for the object.
3. Class version: 1.0
The Class version to help correct marshall and unmarshall of an
object. Maybe support schema evalution.
4. Object version: 1234
This is a version number that is updated each time an object state is
updated. This will be a useful field for the ClientCacheDatabase
implementation.
This is the link to the small device Java VM I talked about in the
beginning of this mail. A cacheclient database is very important for
handheld device, esepcially to support discontinuous operation on the
object. Most handheld can't be always connected. Most of time, a
handheld device is discounted from the net and are required to be
operational with the data it has.
Having a object version will help in conflict detection in this case.
The proper resolution will probably come from work in distributed
database. There are some ideas but not thing concrete.
5. Object identity: 5678
Well... this is it! ;) It's the Object's id in the database.
6. The hashcode. We can probably adapt the URN for the id's hashCode.
The ideas here are largely influenced by the following
I. Webizing existing systems:
http://www.w3.org/DesignIssues/Webize.html
II. Universal Resource Identifiers -- Axioms of Web Architecture
http://www.w3.org/DesignIssues/Axioms.html
III. Naming and Addressing: URIs, URLs, ...
http://www.w3.org/Addressing/
> So, I would like to avoid to have a method that appears to return the object
> ID of an object back to the client. This, IMO, leads to wrong designs. We
> don't need this as Java doen't need pointers. The identityHashCode() in fact
> does nothing else but people would not expect a getObjectByHash() method
> somewhere in the ozone API because such a method does also not exist in the
> Java model in general.
>
> getObjectIdentity() / getObjectByIdentity() are wrong IMO and would break the
> design of ozone.
>
With the above argument on identity and equivlance, I think it's proper
to have methods that return object id to the client. We properly can't
implement a discontinued connecting client cache database without one.
I'd propose the following addition to an OzoneRemote interface:
public interface OzoneRemote {
public String getObjectIdentity();
public String getObjectIdentityHash();
public boolean isSame(Object obj);
}
Also, in the OzoneInterface, add
public Object getObjectByIdentity(String objectIdentity);
David Li
DigitalSesame