If I clone a (possibly detached) persistent object (actually, I would use a copy constructor since clone() is so badly flawed), can I later associate the clone with a hibernate session so that i can navigate/update the clone just like the original object? Or is the original object somehow special in a way that the clone cannot be?

Thanks!

Actually, come to think of it, cloning persistent objects just about /must/ work using a correct clone implementation because it will do field copies of any magically modified/generated fields. But is there some subtle way that using a cloned object like this could mess up Hibernate?

No. Just be careful when using proxys.

okay, so clone() will work. but if i copy construct an object, is there any way to attach that non-persistent object to a hibernate session *as the original* (with the same identity and version)? if not, is this feature possible in some future hibernate?

Yes, just do it using session.lock(object, LockMode.NONE)

okay i think i see what you are saying now. the id and version must be ordinary attributes of the object that i can just copy manually, right?

the trickiness must be all about lazy proxies and navigation...

so what happens if i have Library object that has a lazy collection of books that is being navigated (maybe there are only 100 out of 10000000) books loaded. i want to create a copy of the Library object using an ordinary copy constructor. but i want to be able to navigate the copy just like the original. how would i accomplish this? obviously session.lock can't do this magic because the object already exists and it is non-bytecode-instrumented. wouldn't i need something like session.clone(object)? or is there some workaround to get the copy to have the same proxies as the original?