It's in the contract! Object versions for JavaBeans
Use object versioning to maintain serialization compatibility with your JavaBeans
By Mark Johnson, JavaWorld.com, 03/01/98
- Digg
- Reddit
- SlashDot
- Stumble
- del.icio.us
- Technorati
- dzone
Over the past two months, we've gone into some depth regarding how to serialize objects in Java. (See "
Serialization and the JavaBeans Specification" and "
Do it the `Nescafé' way -- with freeze-dried JavaBeans.") This month's article assumes you've either already read these articles or you understand the topics they cover. You should
understand what serialization is, how to use the
Serializable interface, and how to use the
java.io.ObjectOutputStream and
java.io.ObjectInputStream classes.
Why you need versioning
What a computer does is determined by its software, and software is extremely easy to change. This flexibility, usually considered
an asset, has its liabilities. Sometimes it seems that software is too easy to change. You've undoubtedly run into at least one of the following situations:
- A document file you received via e-mail won't read correctly in your word processor, because yours is an older version with
an incompatible file format
- A Web page operates differently on different browsers because different browser versions support different feature sets
- An application won't run because you have the wrong version of a particular library
- Your C++ won't compile because the header and source files are of incompatible versions
All of these situations are caused by incompatible versions of software and/or the data the software manipulates. Like buildings,
personal philosophies, and riverbeds, programs change constantly in response to the changing conditions around them. (If you
don't think buildings change, read Stewart Brand's outstanding book How Buildings Learn, a discussion of how structures transform over time. See Resources for more information.) Without a structure to control and manage this change, any software system of any useful size eventually
degenerates into chaos. The goal in software versioning is to ensure that the version of software you are currently using produces correct results when it encounters data produced
by other versions of itself.
This month, we're going to discuss how Java class versioning works, so that we can provide version control of our JavaBeans.
The versioning structure for Java classes permits you to indicate to the serialization mechanism whether a particular data
stream (that is, a serialized object) is readable by a particular version of a Java class. We'll talk about "compatible" and
"incompatible" changes to classes, and why these changes affect versioning. We'll go over the goals of the versioning structure,
and how the java.io package meets those goals. And, we'll learn to put safeguards into our code to ensure that when we read object streams of
various versions, the data is always consistent after the object is read.
Version aversion
There are various kinds of versioning problems in software, all of which pertain to compatibility between chunks of data and/or
executable code:
- Differing versions of the same software may or may not be able to handle each others' data storage formats
- Programs that load executable code at runtime must be able to identify the correct version of the software object, loadable
library, or object file to do the job
- A class's methods and fields must maintain the same meaning as the class evolves, or existing programs may break in places
where those methods and fields are used
- Source code, header files, documentation, and build scripts must all be coordinated in a software build environment to ensure
that binary files are built from the correct versions of the source files
This article on Java object versioning only addresses the first three -- that is, version control of binary objects and their
semantics in a runtime environment. (There's a vast array of software available for versioning source code, but we're not
covering that here.)
- Digg
- Reddit
- SlashDot
- Stumble
- del.icio.us
- Technorati
- dzone
Resources
- The initial document that lays it on the line about compatibility between class file versions is the "Binary Compatibility"
section of the Java Language Specification (JLS). This chapter of the JLS specifies all compatible changes to a class that every JVM file must support
http://www.javasoft.com/docs/books/jls/html/13.doc.html
- The complete list of compatible and incompatible changes can be found at http://www.javasoft.com/products/jdk/1.2/docs/gui
- This is a part of the Java Object Serialization Specification, which appears at http://java.sun.com/products/jdk/1.1/docs/guide/serialization/spec/version.doc.html#6678
- What do changing buildings have to do with software? Plenty! Software and buildings are both complex structures that must
change to adapt to new uses and situations if they are to survive. Whereas most architecture books describe how they work
in space, read How Buildings Learn, by Stewart Brand. He discusses how buildings work in time. There are many conceptual parallels to designing software for maintainability. http://www.amazon.com/exec/obidos/ISBN=0140139966/0898-3091519-778439
- For a wild ride along the same lines of thought, check out A Big Ball of Mud, by Brian Foote and Joseph Yoder, at the Department of Computer Science, University of Illinois at Urbana-Champaign. http://laputa.isdn.uiuc.edu/mud/mud.html
- You can download and print the National Institute of Standards and Technology's specification for the SHA-1 secure hash from
http://www.itl.nist.gov/div897/pubs/fip180-1.htm
- Previous JavaBeans columns: