Java Language Integrity & Security: Serializing Classes, Page 3

Removing the Serializable Interface

Before you spend time getting into detail about how objects are serialized, see what happens when you don't serialize an object. You may have noticed the following line of code in the Employee class.

public class Employee implements Serializable {

This is how the Sun documentation describes the Serializable interface.

public interface Serializable

Serializability of a class is enabled by the class implementing the java.io.Serializable interface. Classes that do not implement this interface will not have any of their state serialized or deserialized. All subtypes of a serializable class are themselves serializable. The serialization interface has no methods or fields and serves only to identify the semantics of being serializable. Post a comment Email Article Print Article Share Articles Digg del.icio.us Slashdot DZone Reddit StumbleUpon Facebook FriendFeed Furl Newsvine Google LinkedIn MySpace Technorati Twitter Windows Live YahooBuzz To allow subtypes of non-serializable classes to be serialized, the subtype may assume responsibility for saving and restoring the state of the supertype's public, protected, and (if accessible) package fields.

Perhaps the key phrase in this description is saving and restoring and that "the serialization interface has no methods or fields and serves only to identify the semantics of being serializable." You use the serialization interface to marshal objects over wires when writing to files, networks, and so forth.

Now, eliminate the serialization interface from the Employee class as seen in Listing 5:

Listing 5: The Updated Employee Class

import java.io.*;
import java.util.*;


public class Employee {

   private int employeeNumber;

   Employee(int num) {
      employeeNumber = num;
   }

   public int getEmployeeNumber() {
      return employeeNumber ;
   }

   public void setEmployeeNumber(int num) {
      employeeNumber = num;
   }
}

Compile all the code just as you did when you initially began with this example.

"C:Program FilesJavajdk1.5.0_06binjavac"
   -classpath . Employee.java
"C:Program FilesJavajdk1.5.0_06binjavac"
   -classpath . Client.java
"C:Program FilesJavajdk1.5.0_06binjavac"
   -classpath . Server.java

When you start up the Server, you get business as usual; however, when you run the Client, you get the exception seen in Figure 10, java.io.NotSerializableException.

Click here for a larger image.

Figure 10: The Client Crashes

The NotSerializableException is described in the Java documentation as follows:

public class NotSerializableException extends ObjectStreamException
Thrown when an instance is required to have a Serializable interface. The serialization runtime or the class of the instance can throw this exception.

Based on this exception, you see that you do need to serialize the Employee object by including the Serializable interface. Otherwise, you can't send the object across the network. Knowing that you need the Serializable interface is one thing; however, what is the Serializable interface and what actually does it do? You will explore this in a future article.

Conclusion

In this article, you reconstructed an example from a previous column in this series and altered it to explain how classes are dynamically loaded over a network. You also demonstrated that there are some potential issues that may lead to compromises in the integrity and security of dynamically loaded classes.

The mechanism for marshalling objects across a wire includes the use of the Serializable interface. You were able to see that if the Serializable interface was not included in the Employee class, an exception was generated—in short, you need to utilize the Serializable interface.

In the future, you will explore the Serializable interface in much greater detail to see exactly what it does and how it is used.

Reference

www.sun.com

About the Author

Matt Weisfeld is a faculty member at Cuyahoga Community College (Tri-C) in Cleveland, Ohio. Matt is a member of the Information Technology department, teaching programming languages such as C++, Java, C#, and .NET as well as various Web technologies. Prior to joining Tri-C, Matt spent 20 years in the information technology industry gaining experience in software development, project management, business development, corporate training, and part-time teaching. Matt holds an MS in computer science and an MBA in project management. Besides The Object-Oriented Thought Process, which is now in its second edition, Matt has published two other computer books, and more than a dozen articles in magazines and journals such as Dr. Dobb's Journal, The C/C++ Users Journal, Software Development Magazine, Java Report, and the international journal Project Management. Matt has presented at conferences throughout the United States and Canada.

Page 3 of 3