Craig, if you say they are immutable, that's enough to me. > meaning that for > getObjectId() you can return the key in your implementation's map of > id to instance without copying it.
Thanks for reading my mind. :) Quoting Craig L Russell <[EMAIL PROTECTED]>: > Hi Erik, > > On Jan 29, 2006, at 2:07 PM, [EMAIL PROTECTED] wrote: > > > > > Hi, > > > > Looking at these classes, it seems they could be immutable. Can they? > > These classes are immutable. There is no public interface by which > they can be changed after construction. An implementation can rely on > instances not changing after construction, meaning that for > getObjectId() you can return the key in your implementation's map of > id to instance without copying it. And you can directly put a > parameter of getObjectById into the map. If the user changes the id > (e.g. via reflection) that's their problem. It's not an > implementation bug if they end up messing up the cache. > > > > Secondly, why hashCode is serialized? can't it be recreated on > > deserialize? > > Yes, it could be recreated on deserialize. Just a small CPU vs. space > optimization. > > It's getting a bit late to change this. If you want to propose it, go > ahead. See if you can get other experts to join you. > > Regards, > > Craig > > > > Regards, > > > > Erik Bengtson > > Craig Russell > Architect, Sun Java Enterprise System http://java.sun.com/products/jdo > 408 276-5638 mailto:[EMAIL PROTECTED] > P.S. A good JDO? O, Gasp! > >
