Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsWhite Papers
Discussion GroupsFirst AidDatabasesJavaBeansGUIJava 3DVirtual MachineCORBASecurityToolsGeneral
Java DirectoryOpen Source ProjectsSample Book ChaptersUser GroupsWeb Resources
Related Topics
Databases.NETMore Topics ...

Java Forum / General / August 2007

Tip: Looking for answers? Try searching our database.

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

Thread view: 
Jimmy - 07 Aug 2007 20:06 GMT
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 - 07 Aug 2007 20:13 GMT
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;
   }
}
Thomas Hawtin - 07 Aug 2007 20:20 GMT
>     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
Zig - 08 Aug 2007 06:30 GMT
>>      private static ABC abcObject;
>
[quoted text clipped - 17 lines]
> 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
Thomas Hawtin - 08 Aug 2007 13:16 GMT
> Excerpt from java.io.ObjectOutputStream:
>
[quoted text clipped - 13 lines]
> 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


Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.