>
> For example, Hashtable doesn't specify that equals()/hashCode() need to
> return the same value after the object has been stored in the table, but
the
> behavior is unpredictable if they don't.
But unpredictable to whom? It may very well be someones intention to make
such a change. Were assuming in a relational model that the primary keys
are not natural keys. For instance imagine we create a table where the name
of the company is the natural key. We can therefore create a unique primary
key on the companies name. Now, Weblogic Inc, is acquired and becomes BEA
Inc. Although we "shouldnt" change the primary key, the key is still the
natural key and it is still unique. IN your case you are right, the
contract of Hashtable doesnt guarantee the same object will be returned. It
only guarantees an object which returns the same value of equals() will.
There should be no assumed contract.
I believe this points to why the container probobly shouldnt rely on
equals() and hashCode() of a PK to identify a particular instance of an
entity bean. Remember the spec says PK classes need equals() and hashCode()
of the PK class for CLIENTS to keep track of their keys not servers. We've
already seen this debate with the Fat Key pattern.
>
> Not hard to extend this consideration to PK's.
>
> Be nice to the container and the container will be nice to you :-)
Give the container vendors a clear spec and they will be alot nicer.
Dave Wolf
Internet Applications Division
Sybase
>
> --
> Cedric
>
>
===========================================================================
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the
body
> of the message "signoff EJB-INTEREST". For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
>
>
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".