Have you ever encounterd a <a title="Javadoc for NotSerializableException" href="http://java.sun.com/j2se/1.4.2/docs/api/java/io/NotSerializableException.html">NotSerializableException</a> in staging, or worse, production? Perhaps you’ve run your application for months or years, but then you decided to cluster your web tier and you realize that your container is actually trying to write out your <a title="Javadoc for HttpSession" href="http://java.sun.com/j2ee/sdk_1.3/techdocs/api/javax/servlet/http/HttpSession.html">HttpSession</a>s to some place hither or yon. Perhaps you’re testing after adding that last little feature, only to eventually realize that your brilliant new feature inserts something into the session that prevents serialization.

I’ve encountered such unpleasent experience as those in past projects. Today I wanted to make sure that my Message for a JMS queue was serializable. More than that, I wanted to make sure that the attribute that’s a Typesafe Enum class I’ve used (yeah, I know they’ve added enums in 1.5/5.0) properly deserializes — it shouldn’t create a new object. Here’s the test I used on the enum:

public void testSerialize() throws Exception {
    ByteArrayOutputStream bout = new ByteArrayOutputStream();
    ObjectOutputStream out = new ObjectOutputStream(bout);
    byte[] bytes = bout.toByteArray();
    ObjectInputStream in = new ObjectInputStream(new ByteArrayInputStream(bytes));
    MyEnum enum = (MyEnum) in.readObject();
    assertTrue("Deserialized constant should be exactly the same object as the constant itself.", enum == MyEnum.ENUM_CHOICE);

For more nuances of writing Typesafe Enums, why they’re really needed, and how to use them well, you should really checkout Item 21 of Josh’s book. In the meantime, think about testing your serialization assumptions. Got any suggestions for other serialization areas to watch?