Newsletter sign-up
View all newsletters

Sign up for our Enterprise Java Newsletter

Enterprise Java

It's in the contract! Object versions for JavaBeans

Use object versioning to maintain serialization compatibility with your JavaBeans

  • 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
Comments (1)
Login
Forgot your account info?

Very niceBy Anonymous on August 26, 2009, 8:35 amVery nice article, really really good!

Reply | Read entire comment

View all comments

Add comment
Anonymous comments subject to approval. Register here for member benefits.
Have a JavaWorld account? Log in here. Register now for a free account.
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: