>I wrote a serializer/deserializer only to realize
>that you can't create a new object that
[quoted text clipped - 5 lines]
>deserialize final slots either. The classes
>I'm serializing are immutable data carriers.
IIRC the constructor is not executed on reconstitution. Transient
fields are not reconstituted. As far as I know, final values should
be reconstituted. To deal with the problem, you compose a readObject
method for the class that calls the usual readObject the patches up
the missing fields.
See http://mindprod.com/jgloss/serialization.html
for what I have learned. If you discover errors, please let me know.

Signature
Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.
Wibble - 26 Jan 2006 12:15 GMT
>>I wrote a serializer/deserializer only to realize
>>that you can't create a new object that
[quoted text clipped - 14 lines]
> See http://mindprod.com/jgloss/serialization.html
> for what I have learned. If you discover errors, please let me know.
Thanks R,
I need this to be non-intrusive. I cant/dontWantTo modify the
class definitions. I also need to be able to read this from
notJava. I don't think I can rely on classes implementing
deserializers since I'm not using default java serialization
format.
I'll look at ObjectStreamClass.setPrimFieldValues
and see if it does the job.
> I wrote a serializer/deserializer only to realize
> that you can't create a new object that
[quoted text clipped - 3 lines]
> Am I missing something or do I have to use JNI
> to cheat object creation and field setting?
I fear that -- unless you can change the target classes -- you will be forced
to use JNI.
You might find a third-party serialiser that has already done the work for you,
either to use directly or as a source of code to cannibalise. Someone
mentioned XStream a little while ago:
http://xstream.codehaus.org/
it looks quite good, but I have never used it myself.
-- chris
Wibble0@gmail.com - 26 Jan 2006 18:26 GMT
I figured this out, but its not pretty.
import sun.misc.Unsafe;
private static Unsafe getUnsafe() {
try {
Field field = Unsafe.class.getDeclaredField("theUnsafe");
field.setAccessible(true);
return (Unsafe)field.get(null);
} catch (Exception ex) {
throw new RuntimeException("can't get Unsafe instance", ex);
}
}
private static final Unsafe unsafe__ = getUnsafe();
private static void setBoolean(Field f, Object o, boolean v) {
unsafe__.putBoolean(o, unsafe__.objectFieldOffset(f), v);
}
private static Object newInstance(Class clazz) throws Exception {
return(unsafe__.allocateInstance(clazz));
}
Chris Uppal - 26 Jan 2006 18:33 GMT
> I figured this out, but its not pretty.
>
> import sun.misc.Unsafe;
I'd forgotten about the "unsafe" stuff; never more than glanced at it to be
honest.
Let's hope it's still there in the next release ;-)
(If not you can always stoop to JNI /then/ -- sufficient unto the day are the
evils thereof...)
-- chris
Thomas Hawtin - 26 Jan 2006 19:22 GMT
>> I figured this out, but its not pretty.
>>
[quoted text clipped - 4 lines]
>
> Let's hope it's still there in the next release ;-)
Your hope may come to nowt. I suspect you might find the non-documented
packages disappearing from view.
http://weblogs.java.net/blog/ray_gans/archive/2006/01/where_we_are_wi.html
"So why will Mustang slip to autumn?
"We've recently decided to make changes to address some issues in
sensitive areas of the codebase (e.g., the classloader) ..."
Elsewhere there have been various mumblings about not relying on
undocumented features.
> (If not you can always stoop to JNI /then/ -- sufficient unto the day are the
> evils thereof...)
Remember that sun.misc.Unsafe is not necessarily what it appears. Calls
to those methods will usually be considered intrinsics (just think how
slow NIO buffers would be without that). Using JNI in place may well be
significantly slower.
Tom Hawtin

Signature
Unemployed English Java programmer
http://jroller.com/page/tackline/