How can I build JavaBeans to be version-safe?

Q: How can I design my JavaBeans so that they are very efficiently serialized (e.g. using ExternalizableLite) yet will be both forwards and backwards compatible at the binary level as new versions of those same JavaBeans are introduced?

A: See the attached example containing three sequential versions of a JavaBean class.

The attached .zip for Coherence 3.0 (or the second version of the .zip that supports 2.5.1) is designed to "overlay" an existing Coherence installation: Simple unzip it to the same location that Coherence was installed to. It creates two new command (Windows .cmd) files in the tangosol\bin directory:

versionedbeans-build.cmd
versionedbeans-start.cmd

Open a command window. Go to the Coherence installation directory. Type bin\versionedbeans-build.cmd to build the example classes. (Both java.exe and javac.exe must be available in the path, or the java_home environmental variable must be configured properly.)

Then type bin\versionedbeans-start.cmd v1. Open another command window, go to the Coherence installation directory, and type bin\versionedbeans-start.cmd v2. Open another command window, go to the Coherence installation directory, and type bin\versionedbeans-start.cmd v3.

Now from any of those command windows, you can type help to get specific help on what commands are available. Here's an example usage:


Command: list
Cache.size()=0
(iterated 0 Address objects)

Command: ver
Address.CURRENT_VERSION=3

Command: new
Current=Address{Street=null, Street2=null, City=null, State=null, PostCode=null, Country=null, serialization version=3}

Command: set Street 48 Grove St.
Current=Address{Street=48 Grove St., Street2=null, City=null, State=null, PostCode=null, Country=null, serialization version=3}

Command: set Street2 Suite 201 (Tangosol, Inc.)
Current=Address{Street=48 Grove St., Street2=Suite 201 (Tangosol, Inc.), City=null, State=null, PostCode=null, Country=null, serialization version=3}

Command: set City Somerville
Current=Address{Street=48 Grove St., Street2=Suite 201 (Tangosol, Inc.), City=Somerville, State=null, PostCode=null, Country=null, serialization version=3}

Command: set State MA
Current=Address{Street=48 Grove St., Street2=Suite 201 (Tangosol, Inc.), City=Somerville, State=MA, PostCode=null, Country=null, serialization version=3}

Command: set PostCode 02144
Current=Address{Street=48 Grove St., Street2=Suite 201 (Tangosol, Inc.), City=Somerville, State=MA, PostCode=02144, Country=null, serialization version=3}

Command: set Country USA
Current=Address{Street=48 Grove St., Street2=Suite 201 (Tangosol, Inc.), City=Somerville, State=MA, PostCode=02144, Country=USA, serialization version=3}

Command: store 1
Command:

The Address bean does not have a Country property in v2, and it has neither a Country nor a Street2 property in v1. The Address bean is both fully forwards compatible and backwards compatible:

If a bean created by v1 is loaded in v2 or v3, or if a bean created by v2 is loaded by v3, the version will automatically update and the additional properties in the newer version will automatically default.
If a bean created or modified by v3 is loaded in v1 or v2, or if a bean created or modified by v2 is loaded in v1, the version will not be changed, and any additional properties of the newer version will not be lost or damaged (although they obviously will be unknown by the older version).

Q: In a v1 test client, the list command returns the 3 generation of objects with the correct serialization version (1, 2, or 3). In a v2 test client, object of generation 1 and 2 are listed with a serialization version = 2 object of generation 3 are listed with a serialization version = 3. And, in the v3 test client, objects of generation (1,2, and 3) are listed with a serialization =3. Why is that?

A: When the object is loaded by a newer version (e.g. created in v1 but listed in v3), the version is automatically updated.

If you were to new and set .. and store 1 in v1, then simply list in v2 an v3, you would see version 2 in v2 and version 3 in v3, because as it listed the objects (i.e. getting them from the cache) it would upgrade the versions on the fly. However, going back to v1 and doing a list would still show version 1 because the updated versions (seen in v2 and v3) were not stored back into the cache.

On the other hand, if you were to new and set .. and store 1 in v1, then simply load 1 and store 1 in the v3, the version in the cache would be v3 (updated by the load and placed into the cache by the store). Now you can go back to v1 and do a list, and it will show version 3 for that Address. However, you can still load 1 and set .. and store 1 from v1, and the version of the Address will stay version 3, and any version 3 information (e.g. Country) would not be lost.

Attachments:

tangosol-v251-example-versionedbeans.zip (application/zip)

tangosol-example-versionedbeans.zip (application/zip)