Re: Cloning Calendar proxies

[Craig L Russell]

Hi Kevin,

On Oct 4, 2007, at 1:00 PM, Kevin Sutter wrote:

Hi,

.equals() method.

It seems that the IBM JDK is cloning a Calendar object when performing the

Why is that?

If I call .equals() on one of our Calendar proxy objects,
the underlying implementation seems to be cloning the object before

methods is called.  Since this is a cloned Calendar proxy, we do some
processing to access the associated StateManager.

determining the equality. While using this cloned object, one of the setter

Seems like the clone should be treated as detached, which implies that we implement our own clone() method, something like: load fields from database; super.clone(); StateManager = null; return;

But, that requires access

object and we end up throwing an IllegalStateException.  Due to that
exception, the .equals() always returns false.


for some guidance from the original developers...

o  Should we override the clone() method?  And, if we do, should we be

that a fully populated Calendar proxy object get returned?

to a Broker and there is no Broker instance associated with this cloned So, before I start experimenting with various fix strategies, I'm looking returning a non-proxy version of a Calendar object? Or, should we ensure

I'm not clear what you mean by "fully populated Calendar". Do you mean simply instantiated with values from the database? If so, yes.

implement the javadoc for these object types.

o Or, should we think about overriding the .equals method on the Calendar proxies? I'm not too thrilled with this since then we'll be attempting to

Oh oh. Please no.

Craig

the IBM JDK.

Thoughts or suggestions?
Kevin

Whatever we determine will probably apply to all of our proxy object types, even though we're only hitting this problem with the Calendar proxy due to

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!

smime.p7s
Description: S/MIME cryptographic signature