|
Home > Archive > Apache JDO Project > January 2006 > make SingleFieldIdentity immutable?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
make SingleFieldIdentity immutable?
|
|
| erik@jpox.org 2006-01-29, 8:46 pm |
|
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
| |
| Craig L Russell 2006-01-29, 8:46 pm |
| | |
| erik@jpox.org 2006-01-29, 8:46 pm |
| 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!
>
>
|
|
|
|
|