Hi,

Looking at these classes, it seems they could be immutable. Can they?

Secondly, why hashCode is serialized? can't it be recreated on deserialize?

Regards,

Erik Bengtson

[ Post a follow-up to this message ]

[ Post a follow-up to this message ]

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 <Craig.Russell@sun.com>:

> Hi Erik,
>
> On Jan 29, 2006, at 2:07 PM, erik@jpox.org wrote:
> 
>
> 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. 
>
> 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 
>
> Craig Russell
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
> 408 276-5638 mailto:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>
>

[ Post a follow-up to this message ]