How to write a deserializer?

Discussion in 'Java' started by Wibble, Jan 26, 2006.

  1. Wibble

    Wibble Guest

    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?
    Wibble, Jan 26, 2006
    #1
    1. Advertising

  2. Wibble

    Roedy Green Guest

    On Wed, 25 Jan 2006 22:30:55 -0500, Wibble <>
    wrote, quoted or indirectly quoted someone who said :

    >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.

    --
    Canadian Mind Products, Roedy Green.
    http://mindprod.com Java custom programming, consulting and coaching.
    Roedy Green, Jan 26, 2006
    #2
    1. Advertising

  3. Wibble

    Wibble Guest

    Roedy Green wrote:
    > On Wed, 25 Jan 2006 22:30:55 -0500, Wibble <>
    > wrote, quoted or indirectly quoted someone who said :
    >
    >
    >>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.
    >


    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.
    Wibble, Jan 26, 2006
    #3
  4. Wibble

    Chris Uppal Guest

    Wibble wrote:

    > 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
    Chris Uppal, Jan 26, 2006
    #4
  5. Wibble

    Guest

    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));
    }
    , Jan 26, 2006
    #5
  6. Wibble

    Chris Uppal Guest

    wrote:
    > 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
    Chris Uppal, Jan 26, 2006
    #6
  7. Chris Uppal wrote:
    > wrote:
    >> 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 ;-)


    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
    --
    Unemployed English Java programmer
    http://jroller.com/page/tackline/
    Thomas Hawtin, Jan 26, 2006
    #7
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    1
    Views:
    1,713
  2. R
    Replies:
    0
    Views:
    1,397
  3. shrikant
    Replies:
    0
    Views:
    2,163
    shrikant
    Dec 20, 2006
  4. Daniel Molina Wegener
    Replies:
    0
    Views:
    384
    Daniel Molina Wegener
    Jun 20, 2010
  5. Daniel Molina Wegener
    Replies:
    3
    Views:
    488
    Josh English
    Aug 28, 2010
Loading...

Share This Page