Object implements Serializable, but includes field(s) that do NOT implement Serializable

Discussion in 'Java' started by Jimmy, Aug 7, 2007.

  1. Jimmy

    Jimmy Guest

    Assuming the following snippet ...

    public class SomeClass implements Serializable {
    private static ABC abcObject;
    private transient DEF defObject;
    private GHI ghiObject;

    public SomeClass() {
    }

    public ABC getABCObject() {
    return abcObject;
    }

    public DEF getDEFObject() {
    return defObject;
    }

    public GHI getGHIObject() {
    return ghiObject;
    }
    }

    All ABC, DEF and GHI classes do NOT implement Serializable. Will all
    fields get serialized properly? Or will just one of them is fine? If
    so, which one?

    Thanks,
    Jimmy
     
    Jimmy, Aug 7, 2007
    #1
    1. Advertising

  2. Jimmy

    Jimmy Guest

    Correction to the snippet ... to include all setter methods.

    public class SomeClass implements Serializable {
    private static ABC abcObject;
    private transient DEF defObject;
    private GHI ghiObject;

    public SomeClass() {
    }

    public ABC getABCObject() {
    return abcObject;
    }

    public void setABCObject(ABCObject o) {
    abcObject = o;
    }

    public DEF getDEFObject() {
    return defObject;
    }

    public void setDEFObject(DEFObject o) {
    defObject = o;
    }

    public GHI getGHIObject() {
    return ghiObject;
    }

    public void setGHIObject(GHIObject o) {
    ghiObject = o;
    }
    }
     
    Jimmy, Aug 7, 2007
    #2
    1. Advertising

  3. Re: Object implements Serializable, but includes field(s) that doNOT implement Serializable

    Jimmy wrote:
    >
    > private static ABC abcObject;


    Static fields are not serialised (what would you expect to happen to the
    original value when you deserialised). So this is fine.

    > private transient DEF defObject;


    Transient fields are not serialised. So this does not matter.

    > private GHI ghiObject;


    It's not the type of the reference which is important, but the value
    assigned to that field. Static typing is not applied here (and would be
    unwieldy unless using an ML-style inference technique).

    If the object pointed to by ghiObject was a subtype of GHI which was
    also a subtype of Serializable, that would be fine. null is also fine. A
    non-serialisable instance would not be serialisable. Defining
    serialPersistentFields appropriately or implementing Externalizable (or
    implementing writeObject but not calling defaultWriteObject or putFields
    - very naughty) would also work.

    Tom Hawtin
     
    Thomas Hawtin, Aug 7, 2007
    #3
  4. Jimmy

    Zig Guest

    On Tue, 07 Aug 2007 15:26:31 -0400, Thomas Hawtin
    <> wrote:

    > Jimmy wrote:
    >> private static ABC abcObject;

    >
    > Static fields are not serialised (what would you expect to happen to the
    > original value when you deserialised). So this is fine.
    >
    >> private transient DEF defObject;

    >
    > Transient fields are not serialised. So this does not matter.
    >
    >> private GHI ghiObject;

    >
    > It's not the type of the reference which is important, but the value
    > assigned to that field. Static typing is not applied here (and would be
    > unwieldy unless using an ML-style inference technique).
    >
    > If the object pointed to by ghiObject was a subtype of GHI which was
    > also a subtype of Serializable, that would be fine. null is also fine. A
    > non-serialisable instance would not be serialisable. Defining
    > serialPersistentFields appropriately or implementing Externalizable (or
    > implementing writeObject but not calling defaultWriteObject or putFields
    > - very naughty) would also work.


    Excerpt from java.io_ObjectOutputStream:

    "Serialization does not write out the fields of any object that does not
    implement the java.io.Serializable interface. Subclasses of Objects that
    are not serializable can be serializable. In this case the
    non-serializable class must have a no-arg constructor to allow its fields
    to be initialized. In this case it is the responsibility of the subclass
    to save and restore the state of the non-serializable class. It is
    frequently the case that the fields of that class are accessible (public,
    package, or protected) or that there are get and set methods that can be
    used to restore the state."

    Now, I generally recommend checking that subtypes all implement
    Serializable where necessary, but this suggests that the field ghiObject
    should be ok if either: ghiObject is a subclass of GHI and implement
    sSerializable/Externalizable, or ghiObject is a class that has a public
    no-arg constructor which will leave the object in a suitable state.

    HTH,

    -Zig
     
    Zig, Aug 8, 2007
    #4
  5. Re: Object implements Serializable, but includes field(s) that doNOT implement Serializable

    Zig wrote:
    >
    > Excerpt from java.io_ObjectOutputStream:
    >
    > "Serialization does not write out the fields of any object that does not
    > implement the java.io.Serializable interface. Subclasses of Objects that
    > are not serializable can be serializable. In this case the
    > non-serializable class must have a no-arg constructor to allow its
    > fields to be initialized. In this case it is the responsibility of the
    > subclass to save and restore the state of the non-serializable class. It
    > is frequently the case that the fields of that class are accessible
    > (public, package, or protected) or that there are get and set methods
    > that can be used to restore the state."
    >
    > Now, I generally recommend checking that subtypes all implement
    > Serializable where necessary, but this suggests that the field ghiObject
    > should be ok if either: ghiObject is a subclass of GHI and implement
    > sSerializable/Externalizable, or ghiObject is a class that has a public
    > no-arg constructor which will leave the object in a suitable state.


    It requires *both*:

    * The class implement Serializable somewhere along the line.

    * The first non-serializable subclass have a no-arg constructor. In
    the example, there is absolutely no need for this to be GHI. Indeed, it
    can be necessary to introduce an intermediate subclass purely to provide
    the no-arg constructor.

    It's appears to be common to believe that serializable classes need
    no-args constructors. This is not the case.

    Tom Hawtin
     
    Thomas Hawtin, Aug 8, 2007
    #5
    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:
    2
    Views:
    657
    Roedy Green
    Dec 12, 2005
  2. John Dalberg
    Replies:
    1
    Views:
    6,461
  3. Frank Fredstone
    Replies:
    8
    Views:
    579
    Tom Hawtin
    Jan 18, 2007
  4. Replies:
    8
    Views:
    3,479
  5. david.karr
    Replies:
    0
    Views:
    148
    david.karr
    May 2, 2008
Loading...

Share This Page