Serialization Faq From Jguru

Serialization FAQ From jGuru Generated Sep 13, 2005 1:11:57 PM What is object serialization? Serializing an object involves encoding its state in a structured way within a byte array. Once an object is serialized, the byte array can be manipulated in various ways; it can be written to a file, sent over a network using a socket-based connection or RMI, or persisted within a database as a BLOB. The serialization process encodes enough information about the object type within the byte stream, allowing the original object to be easily recreated upon deserialization, at a later point in time.

How should I declare fields within my serializable class to prevent them from being serialized? Within JDK 1.1, any non-static field declared as transient is not serialized. (Static fields are not serialized anyway) Java 2 provides you with another mechanism for specifying which fields need to be serialized. Your class can declare the static field: public final ObjectStreamField[] serialPersistentFields = {...}; initialized with instances of ObjectStreamField, within each instance indicating the name and type of the serializable field. For example: public class FooBar implements Serialzable { private Foo foo; private int bar; private String passwd; public final static ObjectStreamField[] serialPersistentFields = { new ObjectStreamField("foo",Foo.class), new ObjectStreamField("bar",Integer.TYPE) }; } indicates that only the fields foo and bar must be serialized.

Can I persist my objects using serialization instead of using a relational or object database? No. While serialization is a highly versatile mechanism having numerous applications, your long term storage needs should continue to be addressed by conventional relational or object databases.

Note that serialization does not provide any features for transaction management and concurrency control. Nor does it provide typical database features like indexed access, caching and a query language.

Why am I having an InvalidClassException thrown during the serialization of my object which implements the Externalizable interface? Unlike objects which implement the Serializable interface, it is mandatory for objects implementing the Externalizable interface to also implement a public no-arg constructor. This constructor is the very first thing that is invoked by readExternal() when reconstructing the object from the bytestream. If a public no-arg constructor is absent, then an InvalidClassException is immediately thrown. Why doesn't serialization save the value of static variables? Variables declared as static members are not considered part of the state of an object because they are shared by all instances of that class. Classes which need to preserve the value of static members during serialization should save and restore these values explicitly using private void readObject(ObjectInputStream) and private void writeObject(ObjectOutputStream). How can I speed up serialization? One thing that slows serialization down considerably is the calculation of the serial version unique identifier, or SUID. This value needs to be calculated when an object is written out, because ObjectOutputStream includes it in the serialized version of the object. It also needs to be calculated when an object is read in, because ObjectInputStream needs to compare the SUID of the serialized object to the SUID of the class file to ensure version compatibility. You can turn off this calculation by explicitly defining an SUID in your class. The SUID must be defined as: private static final long serialVersionUID = nnnL; where "nnn" represents a long integer. To ensure backward compatibility with existing serialized objects of that class, you cannot choose an arbitrary long integer here; you must choose the same value that was automatically generated. You can find out what that was by running the Java 2 SDK tool "serialver" on your old class file. Comments and alternative answers

This Is A Myth Author: Daniel Gredler (http://www.jguru.com/guru/viewbio.jsp?EID=1179237), Jun 16, 2004 This is a prevalent Java serialization myth: that you can speed serialization up by hard-coding a SUID. The calculated SUID gets cached, so you only incur the overhead (max 50ms) once. Or maybe more, since they're cached using soft references, but you get the idea. See

http://www.javaworld.com/javaworld/javaqa/2003-06/02-qa-0627-mythser.html? for more details. What is the Stream Unique IDentifier (SUID) that is written out as part of the serial stream? Location: http://www.jguru.com/faq/view.jsp?EID=5060 Created: Jan 15, 2000 Author: Govind Seshadri (http://www.jguru.com/guru/viewbio.jsp?EID=14) The serialization process uses a unique identification value to keep track of the persisted objects. When a Serializable or Externalizable object is saved, it's fullyqualified class name and the Stream Unique IDentifier (SUID) of the class is written out to the stream. The SUID is a unique 64-bit hash, and is obtained by applying the SHA-1 message digest algorithm to the serialized class, including its name, field types and method signatures. This step is important as it prevents the data persisted by one class from being read by another class with the same name. For any class to be able to read successfully from an object stream, it is imperative that its SUID matches the SUID of the serialized data in the stream. What is the purpose of the tool "serialver"? How is it used? Location: http://www.jguru.com/faq/view.jsp?EID=5063 Created: Jan 15, 2000 Author: Govind Seshadri (http://www.jguru.com/guru/viewbio.jsp?EID=14) When an object is serialized, its fully qualified class name, as well as the 64-bit SUID, is written to the stream. Later, when a class attempts to read the serialized object, it is important that its SUID matches that of the serialized object, as otherwise an InvalidClassException is thrown. But therein lies the problem - because, when classes evolve, so do their SUIDs. But luckily, there is a solution at hand in the form of serialver - a utility provided by the Java SDK, which allows us to generate the SUID of a Java class file. If the output of serialver is included within a class file, then that class is now compatible with all it's persisted objects and can be used to read back the same, even though the class definition itself may undergo some mutation down the road. For instance, running: serialver foo.Person generates: foo.Person: static final long serialVersionUID =3734178553292263588L; Now, you can continue to read the foo.Person objects even with future versions of the class, as long as they have the "old" SUID embedded within them as: static final long serialVersionUID =3734178553292263588L;

This will work because a class, before it reads the serialized data from the stream, first checks for the presence of the serialVersionUID field within. If found, its value is written to the stream, instead of one being calculated on the fly. Since the SUID values should now match, there would be no problem in reading in the serialized data. It is probably easier to use a GUI version of serialver, which can be enabled by the -show option. Comments and alternative answers

serialver x? Author: Eric Freiborg (http://www.jguru.com/guru/viewbio.jsp?EID=933773), Jul 1, 2002 Is the parameter passed into serialver the class being serialized (x.class or x.java) or is it the serialized file of that class(x.ser)? Thanks, Eric Re: serialver x? Author: Tim Rohaly (http://www.jguru.com/guru/viewbio.jsp?EID=10), Jul 1, 2002 The argument is the class name. serialver uses the standard Java classloader to search for the class file definition (with file extension .class) in your classpath. The class file definition can be in a jar file as well, as long as that jar file is in your classpath. Try this, for example, to print out the SUID for one of the core JDK classes: serialver java.lang.String

serialver should never really be needed. Author: Richard Martin (http://www.jguru.com/guru/viewbio.jsp?EID=1051951), Jan 30, 2003 The Serialization spec does not mandate that the serialVersionUID declared in the class be any particular value. If you are creating new class, you can declare it with a serialVersionUID of anything your like. As far as I can tell the only reason you would ever want to use serialver is if an earlier version of the class did not declare a serialVersionUID and you then want to make a serial-compatible change to that class. Then you would run serialver on the old class and declare that value in your new class. You then stick with that value until you make a serial-incompatible change, at which point you can use an number you like (obviously different from the original number). If you follow the practise of declaring a serialVersionUID in every serializable class, you would never need to use serialver.

What changes are considered serial-compatible? Author: Eric Rizzo (http://www.jguru.com/guru/viewbio.jsp?EID=10628), Jun 24, 2003 As stated above, it is good practice to declare your own serialVersionUID for all your serializable classes. This allows you to make serial-compatible changes to the class without getting InvalidClassException. But where does the Java spec define exactly what are considered serial-compatible changes and what are not? A link would be appreciated. Re: What changes are considered serial-compatible? Author: Dimas Moreira Junior (http://www.jguru.com/guru/viewbio.jsp?EID=1104012), Jul 25, 2003 The Java Object Serialization Specification specifies which changes are serialcompatible. What are the compatible and incompatible changes when dealing with versioned serialized objects? Location: http://www.jguru.com/faq/view.jsp?EID=5064 Created: Jan 15, 2000 Author: Govind Seshadri (http://www.jguru.com/guru/viewbio.jsp?EID=14) If a newer version of a serialized object has to be compatible with an older version, it is important that the newer version abides by the rules for compatible and incompatible changes. A compatible change is one that can be made to a new version of the class, which still keeps the stream compatible with older versions of the class. Examples of compatible changes are: •

• • •

Addition of new fields or classes does not affect serialization, as any new data in the stream is simply ignored by older versions. When the instance of an older version of the class is deserialized, the newly added field will be set to its default value. You can field change access modifiers like private, public, protected or package as they are not reflected to the serial stream. You can change a transient or static field to a non-transient or non-static field, as it is similar to adding a field. You can change the access modifiers for constructors and methods of the class. For instance a previously private method can now be made public, an instance method can be changed to static, etc. The only exception is that you cannot change the default signatures for readObject() and writeObject() if you are implementing custom serialization. The serialization process looks at only instance data, and not the methods of a class.

Changes which would render the stream incompatible are:

• •

• • • •

Once a class implements the Serializable interface, you cannot later make it implement the Externalizable interface, since this will result in the creation of an incompatible stream. Deleting fields can cause a problem. Now, when the object is serialized, an earlier version of the class would set the old field to its default value since nothing was available within the stream. Consequently, this default data may lead the newly created object to assume an invalid state. Changing a non-static into static or non-transient into transient is not permitted as it is equivalent to deleting fields. You also cannot change the field types within a class, as this would cause a failure when attempting to read in the original field into the new field. You cannot alter the position of the class in the class hierarchy. Since the fully-qualified class name is written as part of the bytestream, this change will result in the creation of an incompatible stream. You cannot change the name of the class or the package it belongs to, as that information is written to the stream during serialization.

Comments and alternative answers

Do the rules for compatible changes require that the... Author: Michael Prescott (http://www.jguru.com/guru/viewbio.jsp?EID=25013), May 29, 2000 Do the rules for compatible changes require that the class versions also have the same serialVersionUID, or does having the same serialVersionUID allow you to enforce compatability when these rules are violated? Can't refactor Author: Alex Chaffee (http://www.jguru.com/guru/viewbio.jsp?EID=3), Aug 15, 2002 In addition to not being able to change the package or name of the class, I believe it is impossible to change the names of serialized fields. Since "rename" is one of the most basic and useful refactorings, this is a big problem. What are the advantages and disadvantags of serialization? Location: http://www.jguru.com/faq/view.jsp?EID=5068 Created: Jan 15, 2000 Author: Govind Seshadri (http://www.jguru.com/guru/viewbio.jsp?EID=14) The advantages of serialization are: • • • • •

It is easy to use and can be customized. The serialized stream can be encrypted, authenticated and compressed, supporting the needs of secure Java computing. Serialized classes can support coherent versioning and are flexible enough to allow gradual evolution of your application's object schema. Serialization can also be used as a mechanism for exchanging objects between Java and C++ libraries, using third party vendor libraries (like RogueWave's Tools.h++ ) within C++. There are simply too many critical technologies that rely upon serialization, including RMI, JavaBeans and EJB.

However, serialization has some disadvantages too: •

• •

It should ideally not be used with large-sized objects, as it offers significant overhead. Large objects also significantly increase the memory requirements of your application since the object input/output streams cache live references to all objects written to or read from the stream until the stream is closed or reset. Consequently, the garbage collection of these objects can be inordinately delayed. The Serializable interface does not offer fine-grained control over object access - although you can somewhat circumvent this issue by implementing the complex Externalizable interface, instead. Since serialization does not offer any transaction control mechanisms per se, it is not suitable for use within applications needing concurrent access without making use of additional APIs.

Comments and alternative answers

Regarding serialization Author: Ravishankar CS (http://www.jguru.com/guru/viewbio.jsp?EID=534441), Mar 21, 2002 Hello, you have mentioned that one of the advantages of serialization is that it can be customized,compressed etc. can u please elaborate on the above 2 points thanking you, Ravishankar Re: Regarding serialization Author: venugopal vasireddy (http://www.jguru.com/guru/viewbio.jsp?EID=828472), Apr 7, 2002 Using Externalizable interfaces you can plug in your own algorithms (compress technics,encription, etc) Does serialization depend on the browser, platform, or VM? Location: http://www.jguru.com/faq/view.jsp?EID=5293 Created: Jan 17, 2000 Modified: 2000-01-17 13:43:08.766 Author: Tim Rohaly (http://www.jguru.com/guru/viewbio.jsp?EID=10) The serialization format is independent of browser, independent of JVM vendor, and independent of platform. So serialization should work with any combination of the above. For example, a serialized object written by Windows can be read by Unix, and vice verse. This is generally true of all I/O in Java. Comments and alternative answers

You did not make any comment regarding different v... Author: Mathew Brozowski (http://www.jguru.com/guru/viewbio.jsp?EID=5786), Jan 20, 2000 You did not make any comment regarding different versions of the JVM. Can a 1.2

server-side Java application serialize an object to an applet in a browser that has a built-in 1.1 version JVM? Compatibility between Java versions is discussed in... Author: Tim Rohaly (http://www.jguru.com/guru/viewbio.jsp?EID=10), Feb 10, 2000 Compatibility between Java versions is discussed in the FAQ found at http://www.jguru.com/jguru/faq/view.jsp?EID=13165 Can I use a BufferedOutputStream with an ObjectOutputStream to serialize an object? Location: http://www.jguru.com/faq/view.jsp?EID=5295 Created: Jan 17, 2000 Modified: 2000-03-13 21:50:27.046 Author: Tim Rohaly (http://www.jguru.com/guru/viewbio.jsp?EID=10) Yes. In fact, it is recommended that you buffer all your input and output unless you have a good reason not to. Here's an example of how to do this: ... String myobject = new String("myobject"); FileOutputStream file = new FileOutputStream("myobject.ser"); BufferedOutputStream bout = new BufferedOutputStream(file); ObjectOutputStream out = new ObjectOutputStream(bout); out.writeObject(myobject); out.flush(); ... Java allows you to chain I/O streams together. Using a BufferedOutputStream makes output much more efficient because the I/O overhead is then expended on large chunks of data, rather than on individual bytes. Likewise, many times it makes sense to compress your output, say if you are writing many large objects to a file or a socket. You can do this using a ZipOutputStream or a GZIPOutputStream in place of (or in addition to!) the BufferedOutputStream in the above example. How can I validate what I've just deserialized? Location: http://www.jguru.com/faq/view.jsp?EID=7476 Created: Jan 22, 2000 Modified: 2000-02-02 10:43:46.655 Author: Tim Rohaly (http://www.jguru.com/guru/viewbio.jsp?EID=10) When an object is deserialized, its internal state is restored to what it was at the time of serialization. So if you serialized a good object, you will get a good object back or an exception will be thrown. However, there are times when you need to check more than just the state of the object. Take for example an object that represents a credit card, including cardholder name, credit card number, and expiration date. If this credit card is deserialized after its expiration date, then although its state is intact, the card is no longer valid and

can't be used in a purchase transaction. This sort of information may be checked in the serializable object's readObject() method. Because serialization saves and restores complete object graphs, you might also imagine there is a need to validate consistency of the entire graph. This cannot be done within a single object's readObject() method - it can only be done after all the objects in the graph are restored. To validate an entire graph, you need to do two things: •

provide an object which implements the java.io.ObjectInputValidation interface register this object with the ObjectInputStream which is reading the graph

•

The java.io.ObjectInputValidation interface defines just the method validateObject() which is declared to throw an InvalidObjectException. Your validator object must provide an implementation for this method which checks the validity of the graph and throws this exception when needed. The validator object must be registered with the stream during the read of the graph; this is usually done within a readObject() method by invoking the registerValidation() method on the ObjectInputStream, passing the stream a reference to the validator object. Here is a short example which shows the mechanics of validation and demonstrates that the validation occurs after the object graph has been reconstituted. This simple example stores objects of type Validate in a collection, and validates upon deserialization that the collection is homogeneous. import java.io.*; import java.util.*; public class Validate implements Serializable, ObjectInputValidation { Vector collection; public Validate(Vector collection) { this.collection = collection; } private void readObject(ObjectInputStream in) throws OptionalDataException, ClassNotFoundException, IOException { System.out.println("reading object"); in.registerValidation(this, 0); in.defaultReadObject(); } private void writeObject(ObjectOutputStream out) throws IOException { }

System.out.println("writing object"); out.defaultWriteObject();

public void validateObject() throws InvalidObjectException { System.out.println("validating object"); Enumeration e = collection.elements(); while (e.hasMoreElements()) { if (!(e.nextElement() instanceof Validate)) throw new InvalidObjectException("Not a homeogeneous collection!"); } } public static void main(String[] args) throws IOException, ClassNotFoundException { Vector collection = new Vector(); for (int i=0; i<10; i++) { Validate obj = new Validate(collection); collection.addElement(obj); } ObjectOutputStream out = new ObjectOutputStream( new FileOutputStream("validate.ser")); out.writeObject(collection); out.flush(); out.close(); ObjectInputStream in = new ObjectInputStream( new FileInputStream("validate.ser")); try { Vector restored = (Vector) in.readObject(); } catch (InvalidObjectException e) { System.out.println("invalid collection!"); } } } Comments and alternative answers

Example Validation Code is "Superfluous" Author: Tony LaPaso (http://www.jguru.com/guru/viewbio.jsp?EID=2330), Dec 2, 2001 Generally, it seems to me the validation mechanism in the Serialization API is pretty much useless -- and the example code I think illustrates this. But maybe I'm wrong... Anyway, the validation performed in the sample code gets executed for each and ever Validate object that gets deserialized. In other words, you can perform the exact same validation at the end of each readObject() method and the effect is that same. To prove the point, I've added a few print statements to the original code to show when and for which objects the validation code is executed. Here is the original code with the added print statements: import java.io.*;

import java.util.*; public class Validate implements Serializable, ObjectInputValidation { Vector collection; public Validate(Vector collection) { this.collection = collection; } private void readObject(ObjectInputStream in) throws OptionalDataException, ClassNotFoundException, IOException { System.out.println("reading object"); in.registerValidation(this, 0); in.defaultReadObject(); System.out.println("FINISHED reading object for object " + hashCode()); } private void writeObject(ObjectOutputStream out) throws IOException { System.out.println("writing object for object " + hashCode()); out.defaultWriteObject(); } public void validateObject() throws InvalidObjectException { System.out.println("validating object for " + hashCode()); Enumeration e = collection.elements(); while (e.hasMoreElements()) { if (!(e.nextElement() instanceof Validate)) throw new InvalidObjectException("Not a homeogeneous collection!"); } } public static void main(String[] args) throws IOException, ClassNotFoundException { Vector collection = new Vector(); for (int i=0; i<10; i++) { Validate obj = new Validate(collection); System.out.println("created new Validate object " + obj.hashCode()); collection.addElement(obj); } ObjectOutputStream out = new ObjectOutputStream( new FileOutputStream("validate.ser")); out.writeObject(collection); out.flush(); out.close(); ObjectInputStream in = new ObjectInputStream( new FileInputStream("validate.ser")); try { Vector restored = (Vector) in.readObject(); }

}

catch (InvalidObjectException e) { System.out.println("invalid collection!"); }

}

I would like to see an example of where the validateObject() method really adds value. In every situation I've seen, however, the code in the validateObject() method could be moved to the end of the readObject() an dthe effect would be the same, but more elegane (IMHO). Can someone provide an example of where validateObject() is really necessary?? Re: Example Validation Code is "Superfluous" Author: John Zukowski (http://www.jguru.com/guru/viewbio.jsp?EID=7), Mar 11, 2002 It is called subclassing. When you subclass, the parent classes validator is called at the end of the child class being initialized, not the parent class. Re: Example Validation Code is "Superfluous" Author: Carl van Denzen (http://www.jguru.com/guru/viewbio.jsp?EID=1138694), Jan 13, 2004 I tried to use the ObjectValidation to restore a static BitSet after restoring an ArrayList. The ArrayList contains objects that contain a unique id number. To track which id numbers are still free I use a BitSet. At the end I couldn't figure out how to register with the stream and I gave up. My solution: after the readObject call, I simply call my validateObject method "manually" and that just works fine. The code looks something like this: class Players extends ArrayList { public Players(String name) { this.name=name; // I do not know the method name getFirstClear usedIdNrs.set(usedIdNrs.getFirstClear()); } BitSet usedIdNrs; static { usedIdNrs.set(0); // skip player number 0 } validateObject() { usedIdNrs.set(0); // do not use number 0 for (i=0;i<size();i++) usedIdNrs.set(get(i).idNr)); } } // end of class main players=in.readObject(); players.validateObject;

What resources are available to read Java serialized output in C++ programs? Location: http://www.jguru.com/faq/view.jsp?EID=10361 Created: Jan 31, 2000 Modified: 2000-01-31 09:37:28.249 Author: Tim Rohaly (http://www.jguru.com/guru/viewbio.jsp?EID=10) Question originally posed by John Zukowski PREMIUM (http://www.jguru.com/guru/viewbio.jsp?EID=7 Tools.h++ Professional by RogueWave http://www.roguewave.com/products/toolspro/ Can an application running in a version 1.1.x JVM read an object that was serialized by an application running in a version 1.2.x JVM? Location: http://www.jguru.com/faq/view.jsp?EID=13165 Created: Feb 10, 2000 Modified: 2000-05-15 19:46:28.884 Author: Tim Rohaly (http://www.jguru.com/guru/viewbio.jsp?EID=10) Changes were made to the default serialization stream format between version 1.1.x and version 1.2.x of the JDK. As a result, if you are writing objects with one version and reading them with another you may have to take special steps to ensure compatibility. There are two distinct forms of the serialization protocol used. These protocol versions are identified by constants in the ObjectStreamConstants class: • •

ObjectStreamConstants.PROTOCOL_VERSION_1 ObjectStreamConstants.PROTOCOL_VERSION_2

The protocol version that is actually used during serialization is determined as follows: • • •

JDK 1.1.x defaults to writing using PROTOCOL_VERSION_1 JDK 1.2.x defaults to writing using PROTOCOL_VERSION_2 JDK 1.1.7 and higher can read both protocol versions

Thus, if both applications use JDK 1.1.7 or higher, the serialization/deserialization will be successful. Applications using JDK version 1.2 and higher may override the default serialization protocol used for writing objects by invoking the useProtocolVersion(int) method on their ObjectOutputStream, where the integer argument is one of the two constants shown above. Setting the protocol version to PROTOCOL_VERSION_1 ensures compatibility with all versions of Java when needed. What is UTF that Serialization uses to write strings? Location: http://www.jguru.com/faq/view.jsp?EID=14685 Created: Feb 15, 2000 Modified: 2000-02-15 22:24:49.342

Author: Tim Rohaly (http://www.jguru.com/guru/viewbio.jsp?EID=10) Question originally posed by John Zukowski PREMIUM (http://www.jguru.com/guru/viewbio.jsp?EID=7 The Java programming language was designed from the ground up to be compatible with multiple character sets from multiple languages. This entails using a non-ASCII character and string representation within the language itself. Internally, Java stores and manipulates all characters and strings as Unicode. Externally, in serialization and in bytecode, Java uses the UTF-8 encoding of the Unicode character set. For each character, UTF-8 encoding is a 1-, 2-, or 3-byte representation of the corresponding 2-byte Unicode character (ASCII characters are encoded as 1 byte, non-ASCII characters are encoded as 2 or 3 bytes). UTF-8 has the property that the ASCII characters 0x20-0x7E encode to UTF-8 1-byte characters of the same value. Therefore, UTF-8 is 100% compatible with existing systems which use ASCII encoding. This is one of the main reasons UTF-8 was chosen for Java's external character representation - it allows complete compatibility with ASCII as well as allowing for a wide range of international characters. For more information, refer to the FAQ What is Unicode? How do I load a serialized applet? Location: http://www.jguru.com/faq/view.jsp?EID=17878 Created: Feb 24, 2000 Modified: 2002-04-30 06:57:05.197 Author: John Zukowski (http://www.jguru.com/guru/viewbio.jsp?EID=7) Instead of specifying the CODE attribute of an <APPLET> tag, you use the OBJECT attribute, as in: <APPLET OBJECT=TheApplet.ser WIDTH=300 HEIGHT=300 > This allows you to preinitialize your applet to some saved state, instead of having to reinitialize your applet each time it is loaded. Support for this in browsers is severly limited. Don't rely on it. I want to have complete control of the binary file format generated by ObjectOutputStream, so I implemented Externalizable in my objects and extended ObjectOutputStream so that I could overwrite the writeStreamHeader() and readStreamHeader() methods. But still when I write data to the stream, some extra information is written. How can I prevent this? Location: http://www.jguru.com/faq/view.jsp?EID=21746 Created: Mar 8, 2000 Modified: 2000-03-08 10:02:53.722 Author: Tim Rohaly (http://www.jguru.com/guru/viewbio.jsp?EID=10) Question originally posed by Radhesh Mohandas (http://www.jguru.com/guru/viewbio.jsp?EID=12979

A serialized object is written out by an ObjectOutputStream and read in by an ObjectInputStream. It is these streams that are responsible for writing and recognizing the binary serialization format. Objects that implement Serializable or Externalizable can only tell the underlying stream what data they want to write out - they don't have control over the binary format. These object streams do allow minimal customization of the protocol. Namely, the ability to override writeStreamHeader() and readStreamHeader() in subclasses. This affects only the magic number and version number written at the beginning of the serialized data, not the internal structure of the data itself. To do any more customization requires you to write your own stream classes. This is true even for primitive types written out through the ObjectOutputStream, because ObjectOutputStream implements its own write() methods to conform to the serialization protocol. As an example, here is a snippet of code which writes out one byte to an ObjectOutputStream: ... FileOutputStream file = new FileOutputStream("test.ser"); ObjectOutputStream out = new ObjectOutputStream(file); out.write(65); out.flush(); out.close(); ... The resulting file, "test.ser", will have a total length of 7 bytes, as follows: 0xACED // ObjectStreamContents.STREAM_MAGIC 0x0005 // ObjectStreamContents.STREAM_VERSION 0x77 // ObjectStreamContents.TC_BLOCKDATA 0x01 // length of data 0x41 // 65 decimal Subclassing ObjectOutputStream and overriding writeStreamHeader() will allow you to change, delete, or add to the first 4 bytes shown above, but that is the limit of customization allowed by overriding. In particular, the block header TC_BLOCKDATA is written by a private method within ObjectOutputStream, so it can't be overridden. There is a lot of logic behind the serialization protocol. From the above example, you see that the protocol writes out an indicator that a block of data follows, then writes out the length of the data, and finally the data itself. This allows efficient reading of the data by a stream, and accomodates variable-length data structures. If you really want to define your own protocol, you will have to write your own input and output stream classes that that use your own binary format. You will then need to use these in place of ObjectInputStream and ObjectOutputStream. You will probably want to implement Externalizable in all your classes as well, so you can control how each object writes its own state. Using ObjectOutputStream, how can I use writeObject() to write the same object twice, so on the other end readObject() will read two separate objects, not two references to the same object?

Location: http://www.jguru.com/faq/view.jsp?EID=25970 Created: Mar 19, 2000 Modified: 2000-03-19 15:28:45.871 Author: Tim Rohaly (http://www.jguru.com/guru/viewbio.jsp?EID=10) Question originally posed by Michael Prescott (http://www.jguru.com/guru/viewbio.jsp?EID=25013 Java's serialization mechanism keeps track of which objects were written to an ObjectOutputStream; when an object is written for the second time a object handle is sent in place of the actual object. This makes the serialization protocol more efficient and allows circular references to be properly dealt with. This algorithm poses a problem if you send an object, make a change to that object, then try to send it again; the receiving end will not read the changed object, it will reconstruct the original object using the object handle. You can tell the ObjectOutputStream to "forget" about previously serialized objects by invoking the reset() method. Resetting the stream causes the stream to behave as if it were just constructed, without any knowledge of what was written to the stream prior to the reset(). You should use this method only when required, otherwise you will end up serializing far more data than necessary. If an object is serialized by a 1.1.x VM, can it be de-serialized by a 1.2.x VM? Location: http://www.jguru.com/faq/view.jsp?EID=28497 Created: Mar 25, 2000 Modified: 2000-03-25 12:33:24.984 Author: Tim Rohaly (http://www.jguru.com/guru/viewbio.jsp?EID=10) Question originally posed by Eric Rath (http://www.jguru.com/guru/viewbio.jsp?EID=26650 Yes. No special steps are needed for this to work. When trying to serialize large strings, or pass large strings as parameters to remote methods, I keep getting a java.io.EOFException. This only happens for strings, not for other large objects. What is the problem? Location: http://www.jguru.com/faq/view.jsp?EID=28687 Created: Mar 26, 2000 Modified: 2001-05-22 08:35:41.241 Author: Tim Rohaly (http://www.jguru.com/guru/viewbio.jsp?EID=10) In Java versions prior to 1.3, there is a limit of 64kB on the size of a serialized String object. This is because ObjectOutputStream delegates String serialization to an instance of DataOutputStream, which writes out the length of a string as a 16bit short, followed by the UTF-8 encoded string. The 64kB limit is due to the maximum value a short datatype can hold. A UTFDataFormatException will be thrown if you try to serialize a String greater than 64kB in these versions of the JDK. This restriction has been removed by implementation changes in Java 2 SDK versions 1.3 and later. If you attempt to deserialize a String larger than 64kB in a pre-1.3 JVM you will get a StreamCorruptedException. Are there any system properties in Java that affect Serialization? Location: http://www.jguru.com/faq/view.jsp?EID=28694

Created: Mar 26, 2000 Modified: 2000-03-26 12:08:01.108 Author: Tim Rohaly (http://www.jguru.com/guru/viewbio.jsp?EID=10) No. Comments and alternative answers

There are some Java Security settings that do affect serializaton, however. Author: Dave Masser-Frye (http://www.jguru.com/guru/viewbio.jsp?EID=939347), Jul 5, 2002 According to the Object Serialization Specification, If the subclass of ObjectInputStream is not considered part of the system domain, a line has to be added to the security policy file to provide to a subclass of ObjectInputStream permission to call enableResolveObject. The SerializablePermission to add is "enableSubstitution". AccessControlException is thrown if the protection domain of the subclass of ObjectStreamClass does not have permission to "enableSubstitution" by calling enableResolveObject. See the document JavaTM Security Architecture (JDKTM 1.2) for additional information about the security model. While this is not technically a property, it is a configuration that must be addressed in rare circumstances. I keep getting an InvalidClassException when I read in my serialized objects. What am I doing wrong? Location: http://www.jguru.com/faq/view.jsp?EID=28705 Created: Mar 26, 2000 Modified: 2000-03-26 22:54:31.294 Author: Tim Rohaly (http://www.jguru.com/guru/viewbio.jsp?EID=10) An InvalidClassException is thrown if the serial version of the object read from the stream does not match that of the loaded class. What probably happened is you changed your class definition since the time you wrote out the serialized instance. To find out how to fix this, see the FAQ at http://www.jguru.com/jguru/faq/view.jsp?EID=5063. Is there a maximum size of a serialized object tree graph? Location: http://www.jguru.com/faq/view.jsp?EID=28713 Created: Mar 26, 2000 Modified: 2000-03-26 20:15:32.955 Author: Tim Rohaly (http://www.jguru.com/guru/viewbio.jsp?EID=10) Question originally posed by John Zukowski PREMIUM (http://www.jguru.com/guru/viewbio.jsp?EID=7 There are limits, but it's difficult to quantify most of them. For example, the JVM stack size affects the graph serialization, since the tree walking is done depth-first, recursively. (This is called post-order traversal.) Too deep a recursion causes stack overflow. This limit can kick in for data structures on the order of 1000 deep, regardless of the size of the objects.

Other, less restrictive limits are that the object handle assigned to each object in a graph is an int, so there is a (rather large) limit on the number of objects in a graph. Likewise, the JVM places a limit on the number of members in an class, so objects have a limit on their size. I think the only practical limit you are likely to encounter is the stack size. This can be avoided by customizing serialization with your own structure-specific readObject() and writeObject() methods. Comments and alternative answers

Passing org.w3c.dom.Document via RMI Author: Kenson ODonald (http://www.jguru.com/guru/viewbio.jsp?EID=1003132), Sep 23, 2002 In encountered the following problem recently. Is this related to the limitation? I got the output by catching a StackOverFlowError. The RMI call looked something like this: rmiApp.pocessDoc(Document doc); How can I get arround this problem? Thanks in advance. java.rmi.MarshalException: error marshalling arguments; nested exception is: java.net.SocketException: Connection aborted by peer: socket write error java.net.SocketException: Connection aborted by peer: socket write error at java.net.SocketOutputStream.socketWrite(Native Method) at java.net.SocketOutputStream.write(SocketOutputStream.java:83) at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:72 ) at java.io.BufferedOutputStream.write(BufferedOutputStream.java:116) at java.io.ObjectOutputStream.drain(ObjectOutputStream.java:1463) at java.io.ObjectOutputStream.setBlockData(ObjectOutputStream.java:1486) at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:407) at sun.rmi.server.UnicastRef.marshalValue(UnicastRef.java:268) at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:106) at com.paetec.oss.bridge.revchain.PTCBridgeRevChainApp_Stub.processServi ceOrderDoc(PTCBridgeRevChainApp_Stub.java:96) at com.paetec.oss.bridge.revchain.PTCBridgeRevChainRmiClient.main(PTCBri dgeRevChainRmiClient.java:313) Can I use an arbitrary long value for serialVersionUID when I declare it in my class? Location: http://www.jguru.com/faq/view.jsp?EID=28715 Created: Mar 26, 2000 Modified: 2000-03-26 15:24:31.6 Author: Tim Rohaly (http://www.jguru.com/guru/viewbio.jsp?EID=10) Question originally posed by Tim Rohaly PREMIUM (http://www.jguru.com/guru/viewbio.jsp?EID=10

If you don't have any previously serialized objects of that class around, you can initialize serialVersionUID to any long value you want. However, if you do have older versions of your class and wish to maintain backward compatibility, you must use the value of serialVersionUID that is determined for you by the serialver command. See http://www.jguru.com/jguru/faq/view.jsp?EID=5063 for more information on serialver. How do I handle versioning of my Externalizable classes? Do I have to write a version number to the stream? Location: http://www.jguru.com/faq/view.jsp?EID=30732 Created: Mar 31, 2000 Modified: 2000-03-31 14:01:00.132 Author: Tim Rohaly (http://www.jguru.com/guru/viewbio.jsp?EID=10) Just as with classes that implement Serializable, the serialVersionUID field is checked when reading in Externalizable objects via an ObjectInputStream. If serialVersionUID is not explicitly defined in your Externalizable class, then one will be computed for you upon deserialization. See the FAQ at http://www.jguru.com/jguru/faq/view.jsp?EID=5063 for more details. How do I use the @serial javadoc tag? Location: http://www.jguru.com/faq/view.jsp?EID=30794 Created: Mar 31, 2000 Modified: 2000-03-31 22:38:18.913 Author: Tim Rohaly (http://www.jguru.com/guru/viewbio.jsp?EID=10) Question originally posed by Tim Rohaly PREMIUM (http://www.jguru.com/guru/viewbio.jsp?EID=10 The @serial javadoc tag is used to document the meaning and acceptable values of serialized fields. It appears in a javadoc comment just prior to a field declaration, and is followed by a free-form field description, which may span more than one line. In the standard javadoc output, this information is displayed only in the "Serialized Form" page for that class. If this serializable field has been added since the initial version of the class, the @since tag should also be used to help document the version changes in the serialized form. How do I use the @serialData javadoc tag? Location: http://www.jguru.com/faq/view.jsp?EID=30795 Created: Mar 31, 2000 Modified: 2000-03-31 22:38:56.837 Author: Tim Rohaly (http://www.jguru.com/guru/viewbio.jsp?EID=10) Question originally posed by Tim Rohaly PREMIUM (http://www.jguru.com/guru/viewbio.jsp?EID=10 The @serialData javadoc tag is used to document methods which generate a serialization format other than the default. In particular, @serialData is typically used to document the writeExternal() method of Externalizable class es and the writeObject method of Serializable classes. It is followed by a free-form description of the data sent to the serialization stream; this should include the order, type, and description of the data. The data description may span more than one line, and may include HTML tags.

What things are required for a class that implements Externalizable? Location: http://www.jguru.com/faq/view.jsp?EID=31433 Created: Apr 3, 2000 Modified: 2000-04-03 10:18:13.694 Author: Tim Rohaly (http://www.jguru.com/guru/viewbio.jsp?EID=10) A class that implements Externalizable must also: • • •

Have a public, no-argument constructor. Provide a writeExternal(ObjectOutput) method to save the state of the object, including the state of any superclass, to the ObjectOutput stream. Provide a readExternal(ObjectInput) method to restore the state of the object, including the state of any superclass, from the ObjectInput stream.

What things are required for a class that implements Serializable? Location: http://www.jguru.com/faq/view.jsp?EID=31434 Created: Apr 3, 2000 Modified: 2000-04-03 22:48:00.577 Author: Tim Rohaly (http://www.jguru.com/guru/viewbio.jsp?EID=10) A class that implements Serializable must also: • •

Have access to a no-argument constructor in its first non-serializable superclass Identify non-serializable data members using the transient keyword or explicitly mark data members as serializable using the serialPersistentFields member.

I'm having trouble getting Externalizable to work. Can you give a simple code example? Location: http://www.jguru.com/faq/view.jsp?EID=32108 Created: Apr 4, 2000 Modified: 2000-04-04 12:07:30.157 Author: Tim Rohaly (http://www.jguru.com/guru/viewbio.jsp?EID=10) Question originally posed by Rama Turaga (http://www.jguru.com/guru/viewbio.jsp?EID=30127 The following code defines a simple Externalizable class that provides a main() method which instantiates an object, writes it to a file, restores it, then verifies that the restored object contains the same values as the original. import java.io.*; import java.util.*; /** * This program demonstrates how to write an Externalizable class */ public class TestExternal implements Externalizable { private String comment = "A serializable data member"; private Vector collection; /** * A no-argument constructor is required for an Externalizable class

*/ public TestExternal() { this(null); } public TestExternal(Vector collection) { this.collection = collection; } /** * This method is responsible for saving the * entire state of the object */ public void writeExternal(ObjectOutput out) throws IOException { out.writeObject(comment); // // You could also just do out.writeObject(collection) below, // but I prefer to loop over the contents and write them one // at a time. // out.writeInt(collection.size()); Enumeration e = collection.elements(); while (e.hasMoreElements()) { out.writeObject(e.nextElement()); } } /** * This method is responsible for restoring the * entire state of the object */ public void readExternal(ObjectInput in) throws ClassNotFoundException, IOException { // // What was written in writeExternal() must be read back here. // comment = (String) in.readObject(); int size = in.readInt(); collection = new Vector(size); for (int i=0; i<size; i++) { collection.addElement(in.readObject()); } } /** * Delegates equality check to the objects stored within * this instance */ public boolean equals(Object o) { if (o instanceof TestExternal) { TestExternal other = (TestExternal) o; if (comment.equals(other.comment) && collection.size() == other.collection.size() ) { for (int i=0; i
} return true;

}

} } return false;

public static void main(String[] args) throws IOException, ClassNotFoundException { // // Create the data to store in this object, // then create and fill the object // Vector bunchOfIntegers = new Vector(); for (int i=0; i<10; i++) { Integer obj = new Integer(i); bunchOfIntegers.addElement(obj); } TestExternal original = new TestExternal(bunchOfIntegers); // // Write the object to a file // ObjectOutputStream out = new ObjectOutputStream( new FileOutputStream("testexternal.ser")); out.writeObject(original); out.flush(); out.close(); // // Now read the object back in from the file // ObjectInputStream in = new ObjectInputStream( new FileInputStream("testexternal.ser")); TestExternal restored = (TestExternal) in.readObject(); // // Compare original object with restored object to // check that they are the same // if (restored.equals(original)) { System.out.println("The original is the same as the restored"); } else { System.out.println("There was a problem with Externalization:"); System.out.println("\tThe original and the restored aren't equal"); } } }

How can I save an Image object using serialization? Location: http://www.jguru.com/faq/view.jsp?EID=32308 Created: Apr 4, 2000 Modified: 2000-05-19 18:25:26.775 Author: Tim Rohaly (http://www.jguru.com/guru/viewbio.jsp?EID=10) Question originally posed by Tim Rohaly PREMIUM (http://www.jguru.com/guru/viewbio.jsp?EID=10 java.awt.Image does not implement Serializable, so if you need to send it to a stream using serialization you must access the underlying data representation and write that representation out explicitly. Fortunately, there's an easy way to do this. Swing provides the javax.swing.ImageIcon class, which can be used as a serializable replacement for Image. ImageIcon has a constructor which accepts an Image, then stores a reference to that Image in a transient instance variable. ImageIcon defines writeObject() and readObject() methods which use the PixelGrabber class to convert the image to an array of integers for writing to the stream and the MemoryImageSource class to restore the image from the stream. An excerpt from the ImageIcon source is shown below. ImageIcon provides a getImage() method for you to recover the stored Image object, so you may either use it directly or you may mimic the technique displayed in the source below to serialize images in your own code. /** * Excerpted from the javax.swing.ImageIcon source code */ public class ImageIcon implements Icon, Serializable { transient Image image; /* body of class has been removed... */ private void writeObject(ObjectOutputStream s) throws IOException { s.defaultWriteObject(); int w = getIconWidth(); int h = getIconHeight(); int[] pixels = image != null? new int[w * h] : null; if (image != null) { try { PixelGrabber pg = new PixelGrabber(image, 0, 0, w, h, pixels, 0, w); pg.grabPixels(); if ((pg.getStatus() & ImageObserver.ABORT) != 0) { throw new IOException("failed to load image contents"); } }

catch (InterruptedException e) { throw new IOException("image load interrupted"); }

}

} s.writeInt(w); s.writeInt(h); s.writeObject(pixels);

private void readObject(ObjectInputStream s) throws ClassNotFoundException, IOException { s.defaultReadObject(); int w = s.readInt(); int h = s.readInt(); int[] pixels = (int[])(s.readObject()); if (pixels != null) { Toolkit tk = Toolkit.getDefaultToolkit(); ColorModel cm = ColorModel.getRGBdefault(); image = tk.createImage(new MemoryImageSource(w, h, cm, pixels, 0, w)); } } } Note that using an integer for each pixel is an extremely inefficient way to save an image. GIF or JPEG encoded images can easily be 10 times more compact. If size is a concern, you might want to investigate other image formats. For example, at http://www.acme.com/ you can find classes that let you write an image out in GIF format. Alternatively, you can compress your array of integers before writing it to the stream. Can I serialize an array directly, or do I have to wrap it in an object first? Location: http://www.jguru.com/faq/view.jsp?EID=34789 Created: Apr 11, 2000 Modified: 2000-04-11 10:46:05.17 Author: Tim Rohaly (http://www.jguru.com/guru/viewbio.jsp?EID=10) Although it's not obvious, arrays in Java are objects; they have methods you can invoke (toString(), equals(), etc.) and contain instance variables (length). The unnamed array superclass also implements Serializable, so all array types can be serialized directly, without any further work from the programmer, as shown in the following code example: public class Test { public static void main(String[] args) throws Exception { // Serialize an int[] ObjectOutputStream out = new ObjectOutputStream(new FileOutputStream("test.ser")); out.writeObject(new int[] {0, 1, 2, 3, 4, 5, 6, 7, 8, 9}); out.flush(); out.close();

// Deserialize the int[] ObjectInputStream in = new ObjectInputStream(new FileInputStream("test.ser")); int[] array = (int[]) in.readObject(); in.close(); // Print out contents of deserialized int[] System.out.println("It is " + (array instanceof Serializable) + " that int[] implements Serializable"); System.out.print("Deserialized array: " + array[0]); for (int i=1; i<array.length; i++) { System.out.print(", " + array[i]); } System.out.println(); } } The usual restrictions apply, of course - if you have an array of objects, the contents of that array must also be serializable in order for the array to be successfully serialized. My subclass implements Serializable but my superclass doesn't. Both subclass and superclass contain instance variables that need to be saved as part of the state of the subclass. Will serialization save the superclass fields for me? Location: http://www.jguru.com/faq/view.jsp?EID=34802 Created: Apr 11, 2000 Modified: 2000-04-11 11:17:31.513 Author: Tim Rohaly (http://www.jguru.com/guru/viewbio.jsp?EID=10) When you serialize an object, the serialization mechanism works by chaining up the inheritence hierarchy, saving the sate of each Serializable superclass in turn. When serialization reaches the first non-serializable superclass, the serialization stops. When deserializing, the state of this first non-serializable superclass is restored not from the stream, but by invoking that class' no-argument constructor. If the noargument constructor is not adequate for your purposes, you must customize the serialization of your subclass with writeObject() and readObject() in order to write out and restore any information from the non-serializable superclass that you find necessary. Are there any other FAQs on Serialization? Location: http://www.jguru.com/faq/view.jsp?EID=35071 Created: Apr 11, 2000 Modified: 2000-04-11 21:08:53.926 Author: Tim Rohaly (http://www.jguru.com/guru/viewbio.jsp?EID=10) Sun's "Frequently Asked Questions on RMI and Object Serialization" is available at http://java.sun.com/products/jdk/1.2/docs/guide/rmi/faq.html. This is a list of FAQs taken from the RMI-USERS mailing list. When using object streams over sockets, I have to flush the streams after each write operation. In fact I even have to flush the output stream soon after creation. Is there a way out of this?

Location: http://www.jguru.com/faq/view.jsp?EID=35512 Created: Apr 12, 2000 Modified: 2000-04-12 12:47:14.803 Author: Tim Rohaly (http://www.jguru.com/guru/viewbio.jsp?EID=10) Question originally posed by Viswanathan Kodaganallur (http://www.jguru.com/guru/viewbio.jsp?EID=35421 The ObjectOutput interface provides a flush() method, implying that implementations are allowed to buffer the output. The semantics of buffered output are such that if you want the data to be sent immediately, you need to flush the buffer (the FAQ at http://www.jguru.com/jguru/faq/view.jsp?EID=32701 talks about this as well). It seems you are expecting to be able to read the data on the other end of the stream immediately after it is written; as you have found out, the only way to ensure that the data is sent over the socket immediately is to flush the buffer. The alternatives, setting the buffer size to be very small or turning off buffering entirely, are not available with socket output streams. The other problem you mention, having to flush the buffer after creation of the ObjectOutputStream, is similar. Instantiating an ObjectOutputStream causes the stream header information to be written to the underlying (buffered) stream. On the other end, instantiating ObjectInputStream causes this header information to be read from the stream. If the output stream buffer hasn't been flushed, then the ObjectInputStream constructor will block until it can read the header information. Hence, when using buffered I/O, it is usually a good idea to flush the ObjectOutputStream right after creation. There is no other way to do this. What role does serialization have in RMI? Location: http://www.jguru.com/faq/view.jsp?EID=37229 Created: Apr 17, 2000 Modified: 2000-04-17 21:17:32.014 Author: Tim Rohaly (http://www.jguru.com/guru/viewbio.jsp?EID=10) Question originally posed by arshad mehmood (http://www.jguru.com/guru/viewbio.jsp?EID=37224 RMI uses serialization as its basic and only mechanism for sending objects across a network. If an object implements java.rmi.Remote, then the object's stub is serialized and sent to the client. If the object implements java.io.Serializable, then the object itself is serialized and sent. Can I pass Externalizable objects by value using RMI, or do the objects have to implement Serializable directly? Location: http://www.jguru.com/faq/view.jsp?EID=38866 Created: Apr 21, 2000 Modified: 2000-04-21 13:33:51.951 Author: Tim Rohaly (http://www.jguru.com/guru/viewbio.jsp?EID=10) RMI will allow you to pass any object that is serializable according to the serialization specification. This includes objects that implement Externalizable as well as objects that implement Serializable.

Note that Externalizable extends Serializable, so anywhere you see the use of the generic term "serializable" you can assume it refers to objects that implement either of these interfaces. How do I use the @serialField javadoc tag? Location: http://www.jguru.com/faq/view.jsp?EID=38867 Created: Apr 21, 2000 Modified: 2000-04-21 16:45:02.083 Author: Tim Rohaly (http://www.jguru.com/guru/viewbio.jsp?EID=10) Question originally posed by Tim Rohaly PREMIUM (http://www.jguru.com/guru/viewbio.jsp?EID=10 If you declare your serialiazable fields using the serialPersistentFields member (see FAQ http://www.jguru.com/jguru/faq/view.jsp?EID=1197) then you should document these fields using the @serialField javadoc tag. The syntax of this tag is: @serialField field-name field-type field-description The serialPeristentFields member is an array of ObjectStreamField objects, declared as follow: private static final ObjectStreamField[] serialPeristentFields; You should have one @serialField tag for each element of the serialPersistentFields array. These tags should appear in the javadoc comment preceding the declaration of serialPersistentFields. In the standard javadoc output, this information is displayed only in the "Serialized Form" page for that class. The javadoc documentation for every Swing class contains the warning that "Serialized objects of this class will not be compatible with future Swing releases." What exactly does this mean, and how does it affect how I write my Swing applications? Location: http://www.jguru.com/faq/view.jsp?EID=38977 Created: Apr 21, 2000 Modified: 2000-04-25 06:11:06.652 Author: Praful Kapadia (http://www.jguru.com/guru/viewbio.jsp?EID=38976) Question originally posed by Tim Rohaly PREMIUM (http://www.jguru.com/guru/viewbio.jsp?EID=10 From the JBuilder documentation: Serializing JavaBeans Serializing an object is the process of turning its state into a sequence of bytes that is neither a .java nor a .class file. Why would you want to do such a thing? That sequence of bytes can be saved as a file on a disk or sent over a network. When a request is made to restore an object from a file or on the other end of a network connection, the sequence of bytes is deserialized into its original structure. For JavaBeans, serialization provides a simple way to save the state of a bean between one session and another. This is also called component persistence. For example, suppose the user of a bean changes the values of several properties. If the bean is serialized to a file and then deserializing the next time the user uses it, the bean is restored exactly as the user left it.

Sun hadn't yet decided the final format for serialized objects. I suspect when they do, they'll opt for XML format. For now you may want to avoid serializing your objects. [FAQ Manager Note] Sun has released the specs of the new XML serialization. See http://java.sun.com/products/jfc/tsc/articles/persistence/index.html for details How can I make a deep copy of an object using serialization? Location: http://www.jguru.com/faq/view.jsp?EID=39089 Created: Apr 22, 2000 Modified: 2000-04-22 11:22:15.904 Author: Tim Rohaly (http://www.jguru.com/guru/viewbio.jsp?EID=10) See http://www.jguru.com/jguru/faq/view.jsp?EID=20435. Why would I want to implement Externalizable instead of Serializable? Location: http://www.jguru.com/faq/view.jsp?EID=42504 Created: Apr 30, 2000 Modified: 2000-05-01 09:45:05.552 Author: Andre van Dalen (http://www.jguru.com/guru/viewbio.jsp?EID=7570) Question originally posed by Tim Rohaly PREMIUM (http://www.jguru.com/guru/viewbio.jsp?EID=10 By implementing Externalizable yourself you can win performance at the cost of flexibility and extra code to maintain. If you implement Externalizable yourself you stream the data directly without the need for reflection which is used in the case of Serializable. See http://developer.java.sun.com/developer/TechTips/2000/tt0425.html for an example. Comments and alternative answers

Externalization is also useful for working around ... Author: Paul Brinkley (http://www.jguru.com/guru/viewbio.jsp?EID=298984), Feb 7, 2001 Externalization is also useful for working around serialization bugs in classes you don't control. For instance, a third-party (or JFC!) class may be specified as Serializable, but it throws an exception when serialized or deserialized. You can subclass this class into one that's Externalizable and define a no-argument constructor for it. The implement your constructor to call whichever superclass constructor pleases you. Implement writeExternal() by saving off the fields you're interested in. Implement readExternal() to read these fields back in and reconfigure the superclass. In this way, you effectively take over all serialization work; it's as if the superclass doesn't even implement Serializable. ObjectOutputStream seems to be holding a reference to all the objects in my large graph, even after I close the stream. This keeps my objects from being

garbage collected. Is this a bug? Location: http://www.jguru.com/faq/view.jsp?EID=42980 Created: May 1, 2000 Modified: 2000-05-01 11:38:10.933 Author: Tim Rohaly (http://www.jguru.com/guru/viewbio.jsp?EID=10) ObjectOutputStream holds a reference to all the objects in the graph so it can handle circular references by noticing when an object has already been serialized. The only way to clear these references is by invoking reset() on the stream. The close() method does not do this, so unless you reset the stream explicitly, those references will be held until the ObjectOutputStream instance is itself garbage collected. This may take some time. Comments and alternative answers

Is this also true with ObjectInputStream? Author: Joen Moreno (http://www.jguru.com/guru/viewbio.jsp?EID=134600), Nov 8, 2000 Is this also true with ObjectInputStream? I keep getting a StackOverflowError when I try to serialize my objects. What does this mean and how can I stop it? Location: http://www.jguru.com/faq/view.jsp?EID=42981 Created: May 1, 2000 Modified: 2000-05-01 11:38:58.566 Author: Tim Rohaly (http://www.jguru.com/guru/viewbio.jsp?EID=10) Serialization is a recursive process. If your object graph is too deep, then you could overflow the JVM stack. To prevent this, implement readObject() and writeObject() and use your superior knowledge of the structure of your object graph to efficiently serialize your objects. How can I programmatically obtain the serialVersionUID for a class? Location: http://www.jguru.com/faq/view.jsp?EID=42982 Created: May 1, 2000 Modified: 2000-11-26 08:58:05.403 Author: Tim Rohaly (http://www.jguru.com/guru/viewbio.jsp?EID=10) The following piece of code shows you how to do this for the class java.lang.String: String s = new String("test"); Class cl = s.getClass(); long uid = ObjectStreamClass.lookup(cl).getSerialVersionUID(); The value of uid will be the same as the value printed out by serialver java.lang.String. What are the writeReplace() and readResolve() methods used for? Location: http://www.jguru.com/faq/view.jsp?EID=44039 Created: May 3, 2000 Modified: 2000-05-03 11:08:47.974 Author: Chuck McCorvey (http://www.jguru.com/guru/viewbio.jsp?EID=42393) Question originally posed by Tim Rohaly PREMIUM (http://www.jguru.com/guru/viewbio.jsp?EID=10

These methods are used to allow an object to provide an alternative representation for itself within an ObjectStream. Consider for instance the common means of implementing an enumerated type: public class Gender implements Serializable { public final static Gender MALE = new Gender("Male"); public final static Gender FEMALE = new Gender("Female"); private String name; private Gender(String name) { this.name = name; } } This works fine within one JVM; there will be at most two Gender objects created, no matter how often you use Gender.MALE and Gender.FEMALE in your code. However, consider what happens when an instance of this class is serialized across JVMs. The ObjectInputStream will create a new instance of Gender that has the same value as the original instance. So, if you have many thousands objects that have been deserialized via RMI you might end up with many thousands of extra instances of Gender. The writeReplace() and readResolve() methods are the hook to solve this problem. One way of eliminating the extra instances and some of the unnecessary heap allocation would be to do something like this: public class Gender implements Serializable { public final static Gender MALE = new Gender("Male"); public final static Gender FEMALE = new Gender("Female"); private String name; private Gender(String name) { this.name = name; } Object writeReplace() throws ObjectStreamException { if (this.equals(MALE)) { return SerializedForm.MALE_FORM; } else { return SerializedForm.FEMALE_FORM; } } private static class SerializedForm implements Serializable { final static SerializedForm MALE_FORM = new SerializedForm(0); final static SerializedForm FEMALE_FORM = new SerializedForm(1); private int value; SerializedForm(int value) { this.value = value; }

Object readResolve() throws ObjectStreamException { if (value == MALE_FORM.value) { return Gender.MALE; } else { return Gender.FEMALE; } }

} } This also guarantees that in all cases where genderInstance.equals(MALE) is true, genderInstance == Gender.MALE is also true. This was a trivial example. I've used this mechanism in other instances where a great deal of storage or time could be saved by serializing only a shorthand or mnemonic form of the object - consider the definition of a currency which could be serialized as only its mnemonic symbol. How has Serialization changed in the Java 2 SE SDK, v1.3? Location: http://www.jguru.com/faq/view.jsp?EID=44246 Created: May 3, 2000 Modified: 2000-05-03 17:32:13.317 Author: Tim Rohaly (http://www.jguru.com/guru/viewbio.jsp?EID=10) Serialization has improved in three key ways: 1. Speed of reading and writing serialized objects was improved up to 40%. This also dramatically improves RMI performance. 2. Limit of 64K on the size of strings has been removed. This entailed changes in the serialization protocol. Older versions of the Java SDK still can't read these long Strings, and will generate a java.io.StreamCorruptedExceptio if they encounter this new protocol. 3. More specific information is reported when an exception occurs during deserialization. This is important for RMI because code movement and dynamic class loading are particularly hard to debug unless specific error messages are generated. Is writing an object to an ObjectOutputStream a thread-safe operation? Location: http://www.jguru.com/faq/view.jsp?EID=44251 Created: May 3, 2000 Modified: 2000-05-03 17:36:32.876 Author: Tim Rohaly (http://www.jguru.com/guru/viewbio.jsp?EID=10) Absolutely not! Serialization, i.e. passing an object reference to the writeObject() method of ObjectOutputStream, is not an atomic operation. Serialization involves traversing a graph of objects, each of which contributes to the state of the object being serialized, saving the state of each object in turn. This is a time-consuming procedure; if other threads are allowed to concurrently access or modify any one of the objects in the graph you could get underfined and unwanted results. The solution is to protect the objects in the graph from modification during the serialization, or to design your objects such that the graph is consistent even if individual objects are modified during serialization. This is, in general, a non-trivial task. Proper use of the transient keyword and customization of serialization

through the use of readObject() and writeObject() will allow you to control exactly what parts of your graph are serialized. Does serialization support encryption? Location: http://www.jguru.com/faq/view.jsp?EID=44567 Created: May 4, 2000 Modified: 2000-05-04 08:37:06.035 Author: Tim Rohaly (http://www.jguru.com/guru/viewbio.jsp?EID=10) Not directly. I/O in Java is performed through streams, and encryption is typically implemented as an algorithm operating on a stream - the input to the stream is clear text, the output is encrypted. Serialization is stream-oriented, so any encryption that can be performed on any stream can also be applied to serialized objects. Comments and alternative answers

GZip can give limited encryption Author: Simon Billingsley (http://www.jguru.com/guru/viewbio.jsp?EID=458934), Jul 20, 2001 When performing serialization you can provide limited encryption of the data within the serialized file by passing the file data through a GZIP filter before writing it to disk. You then need to rememember to pass it through a GZIP filter on the way back in. Although this isn't true encryption, because they can always 'decrypt' the data using gunzip on the command line, it prevents the data from being viewed in a file editor directly. See the classes java.util.zip.GZipOutputStream and java.util.zip.GZipInputStream for more information. Can an object of type Class be serialized? Location: http://www.jguru.com/faq/view.jsp?EID=48741 Created: May 13, 2000 Modified: 2000-05-15 20:23:48.879 Author: raghu rao (http://www.jguru.com/guru/viewbio.jsp?EID=48735) Question originally posed by Tim Rohaly PREMIUM (http://www.jguru.com/guru/viewbio.jsp?EID=10 Yes, it can. Class implements Serializable, so a object of type Class can be serialized. Comments and alternative answers

All versions of Java through 1.3 have a bug doing this... Author: Marius Strumyla (http://www.jguru.com/guru/viewbio.jsp?EID=29146), May 30, 2000

All versions of Java through 1.3 have a bug doing this for some cases. On an attempt to deserialize classes of primitive types (e.g., int.class, boolean.class), the JVM throws a java.lang.ClassNotFoundException. For possible workaround to this bug see http://developer.java.sun.com/developer/bugParade/bugs/4171142.html.

What are the security considerations for serialization? Location: http://www.jguru.com/faq/view.jsp?EID=57249 Created: May 25, 2000 Modified: 2000-05-25 23:59:27.342 Author: Tim Rohaly (http://www.jguru.com/guru/viewbio.jsp?EID=10) The Java runtime environment has many features that contribute to security and robustness in a program. For example, the runtime environment enforces access permissions to private, protected, or "default" members. But when you serialize your objects, you are in effect removing them from the runtime environment, thereby exposing them to access that would normally not be allowed - e.g. anyone can come along and read the contents of a private variables from a serialized object. This is why it is important to consider security when you are designing your classes for serialization. Java provides a number of mechanisms to protect your serialized code: •

•

• • •

The first is the obvious step that classes need to be explicitly declared as implementing Serializable or Externalizable - your class cannot be serialized without a concious decision on your part to make it so. Java provides a transient keyword which prevents a primitive type or object reference from being written to the stream. You may use this to control which information is sent out. For example, you may mark a private password field as transient so that it isn't written out - this prevents someone from coming along and reading your password directly from a serialized object. Serialization is a stream-oriented process, so you may apply any streambased encryption to your serialized objects. Deserialization can't overwrite existing objects in memory - it can only create new objects. Loading classes for serialized objects is done through the normal class loader mechanism, therefore is protected by the usual Java security mechanisms.

One other things to consider: If you are implementing Externalizable, both readExternal() and writeExternal() are public, so it is possible to replace objects in memory when reading and it is possible to override writeExternal() to gain access to private data when writing. If you want to enforce safety, you should either not use Externalizable or take additional steps to avoid these problems. The above is not a comprehensive list; more information on this subject may be found at: http://java.sun.com/security/seccodeguide.html and

http://java.sun.com/products/jdk/1.2/docs/guide/serialization/spec/security.doc.html . How can I read and write serialized objects to and from a database? Location: http://www.jguru.com/faq/view.jsp?EID=74403 Created: Jun 13, 2000 Modified: 2000-06-13 12:12:18.258 Author: Simon Brown (http://www.jguru.com/guru/viewbio.jsp?EID=44588) Question originally posed by edwin abiraham (http://www.jguru.com/guru/viewbio.jsp?EID=41880 If your RDBMS supports them, you can store serialized objects as BLOBs. These are JDBC 2.0 features, but take a look at java.sql.Blob, ResultSet and PreparedStatement for more information. Comments and alternative answers

Storing Objects as Text Author: Scott McKinney (http://www.jguru.com/guru/viewbio.jsp?EID=727047), Jan 19, 2002 You could store relatively small objects in VARCHAR fields by encoding the byte array e.g., using the Base64 encoding. Alternatively, instead of using standard java serialization you might consider storing an object in XML using your own (or third-party) serialization scheme. Since the objects are stored in XML you have the benefit using VARCHAR fields as well. Base64 Encoding Author: Stephen Ostermiller (http://www.jguru.com/guru/viewbio.jsp?EID=576685), Sep 24, 2002 Open source, GPL implementation from com.Ostermiller.util: http://ostermiller.org/utils/Base64.html It can encode and decode strings, byte arrays, files, and streams. Open source, public domain encoder/decoder by Robert W. Harder: http://iharder.sourceforge.net/base64/ Encodes to strings from several formats including byte arrays and strings. It has a method of encoding and decoding streams but it looks awkward. Open source, freeware (except military) from Roedy Green's Java Glossary: http://mindprod.com/jglossbase64.html http://mindprod.com/products.html#BASE64 Encodes from byte arrays to strings, decodes from strings to byte arrays. Open source, GPL implementation by Kevin Kelley: http://kevinkelley.mystarband.net/java/goodies.html

Encodes and decodes from byte arrays to byte arrays. Open source, freeware (any purpose with attribution) by Bob Withers: http://www.ruffboy.com/download.htm Encodes and decodes from byte arrays to byte arrays and comes with C++ code too. JavaWorld tip with annotated code and nifty graphic that shows how Base64 encoding works (license unknown). http://www.javaworld.com/javaworld/javatips/jw-javatip36-p2.html Supports byte array to byte array operations. I am able to write an object using ObjectOutputStream but when I try to read the object back using ObjectInputStream I get a StreamCorruptedException. How can I overcome this? Location: http://www.jguru.com/faq/view.jsp?EID=76047 Created: Jun 14, 2000 Modified: 2001-05-22 08:27:30.431 Author: Tim Rohaly (http://www.jguru.com/guru/viewbio.jsp?EID=10) Question originally posed by Kartick Neogi (http://www.jguru.com/guru/viewbio.jsp?EID=50612 The serialization specification says that a StreamCorruptedException is thrown: • • • •

If the stream header is invalid. If control information not found. If control information is invalid. JDK 1.1.5 or less attempts to call readExternal() on a PROTOCOL_VERSION_2 stream.

The last item is probably the most common problem - it will occur if you write out an Externalizable object using Java version 1.2 and try to read it in using Java version 1.1.5 or less. The other reasons might occur if, for example, you transferred the .ser file to a different computer by FTP and forgot to use binary mode. One additional cause of StreamCorruptedException that is not explicitly mentioned in the specification is if you try to deserialize a String of length >64kB into a preversion 1.3 JVM. Prior to Java version 1.3, serialization of String objects of this length was not supported. Comments and alternative answers

How can get rid of serialize ID or make it unchange in respect to different version of jdk? Author: Stephen Koo (http://www.jguru.com/guru/viewbio.jsp?EID=477108), Aug 14, 2001 I use VisualAge for Java (jdk 1.2.2) to program the DefaultStyledDocument, I have

generated and save some data in the IDE too. Afterthat, I deployed the application and use standard Java runtime engine 1.3x to execute it, but the program cannot read back the saved data in the IDE, the error is as follows: java.io.InvalidClassException: javax.swing.text.DefaultStyledDocument; Local class not compatible: stream classdesc serialVersionUID=-3720453677177430838 local class serialVersionUID=3189459741008450845 at java.io.ObjectStreamClass.validateLocalClass(Unknown Source) at java.io.ObjectStreamClass.setClass(Unknown Source) at java.io.ObjectInputStream.inputClassDescriptor(Unknown Source) at java.io.ObjectInputStream.readObject(Unknown Source) at java.io.ObjectInputStream.readObject(Unknown Source) at java.io.ObjectInputStream.inputObject(Unknown Source) at java.io.ObjectInputStream.readObject(Unknown Source) at java.io.ObjectInputStream.readObject(Unknown Source) at Formatter.doOpenCommand(Formatter.java:172) at Formatter$2.actionPerformed(Formatter.java:49) at javax.swing.AbstractButton.fireActionPerformed(Unknown Source) at javax.swing.AbstractButton$ForwardActionEvents.actionPerformed(Unknow n Source) at javax.swing.DefaultButtonModel.fireActionPerformed(Unknown Source) at javax.swing.DefaultButtonModel.setPressed(Unknown Source) at javax.swing.AbstractButton.doClick(Unknown Source) at javax.swing.plaf.basic.BasicMenuItemUI$MouseInputHandler.mouseRelease d(Unknown Source) Can I serialize an object that has native methods? Location: http://www.jguru.com/faq/view.jsp?EID=77054 Created: Jun 15, 2000 Modified: 2000-06-15 12:23:17.667 Author: Tim Rohaly (http://www.jguru.com/guru/viewbio.jsp?EID=10) Method implementations, whether native or pure Java, are not part of the serialized state of an object. There is nothing that prevents objects with native methods from being serialized. It might however be problematic in practice to reconstitute these objects if the native code can't be loaded, e.g. when sending serialized objects over a socket where the other end doesn't have the native library installed. It is of course also a problem if the other end can't load the .class files, but native libraries can't be dynamically downloaded like .class files. Is there a way to serialize an object as an XML document? Location: http://www.jguru.com/faq/view.jsp?EID=79287 Created: Jun 18, 2000 Modified: 2000-06-18 00:58:13.512 Author: John Zukowski (http://www.jguru.com/guru/viewbio.jsp?EID=7) Question originally posed by Daniel Jutzi (http://www.jguru.com/guru/viewbio.jsp?EID=43200

The Java serialization mechanism uses an efficient, compact format for encoding information about class structure and the values for instance variables. The eXtensible Markup Language (XML) provides a text-based approach for encoding structured data, and could also be used to encode the serialization information, albeit in a much less compact but more readable format. It should come as no surprise that this approach is being investigated to determine if it is appropriate under certain circumstances. The reference at the end of this answer provides a link to an article by Philip Milne and Kathy Walrath at The Swing Connection which illustrates such a technique by defining a persistence model which writes object graphs as XML documents. In this article, they define, among other things, an XML format for JavaBeans, and streams XMLOutputStream and XMLInputStream. The following is an example taken from that article which illustrates the XML format for a simple serialized JPanel object. <JAVA-OBJECT-ARCHIVE VERSION="0.1">