How to write a deserializer?

[Wibble]

I wrote a serializer/deserializer only to realize
that you can't create a new object that
doesn't have a noArg constructor or populate
final slots.

I'm serializing a large structure. Java default
serialization gets stack overflows and won't
deserialize final slots either. The classes
I'm serializing are immutable data carriers.

Am I missing something or do I have to use JNI
to cheat object creation and field setting?

 

[Roedy Green]

I wrote a serializer/deserializer only to realize
that you can't create a new object that
doesn't have a noArg constructor or populate
final slots.

I'm serializing a large structure. Java default
serialization gets stack overflows and won't
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.

 

[Wibble]

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.

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.

 

[Chris Uppal]

I wrote a serializer/deserializer only to realize
that you can't create a new object that
doesn't have a noArg constructor or populate
final slots.
[...]
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]

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]

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]

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 ;-)

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