make SingleFieldIdentity immutable?

[er...@jpox.org]

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

Re: make SingleFieldIdentity immutable?

[er...@jpox.org]

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

> Hi Erik,
>
> On Jan 29, 2006, at 2:07 PM, erik@jpox.org 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:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>
>

Re: make SingleFieldIdentity immutable?

[Craig L Russell <Cr...@Sun.COM>]

Hi Erik,

On Jan 29, 2006, at 2:07 PM, erik@jpox.org 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:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!