Featured White Papers

• Java Web Hosting | DailyRazor.com - Over 10yrs Of Java Web Hosting Exp!

Sponsored Links

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

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

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.)