What (if any) languages are actually good at versioning? Is it always something you have to graft into the language?

.Net versions every Class in addition to the serialized version of the Class instance. This allows them a lot of flexibility because they have the ability to see what version a Class is and distinquish between two different versions of a Class in the VM. Python does some cool things with Class loading and scoping of Classes. The thing to keep in mind with Java is that a Class instance and the Class object only know the ClassLoader that they came from. They don’t know what version they are, who called them, who they might call, what dependencies they have, how they were deployed, etc. This means that you have to do all versioning using ClassLoader magic and custom code on top of Java.

Can’t you use the serialVersionUID to determine if a enum has changed (forgive my ignorance, as I haven’t done much with enums)?

My example actually assumes you have added a serialVersionUID to the type safe enum (non JDK 1.5). If you haven’t, you won’t even have the opportunity to return null or throw an exception from the readResolve method because the serialization will throw a UnmarshalException instead. Additionally, JDK 1.5 enums don’t get new serialVersionUIDs when you add or subtract a enum value. This is different than type safe enum pattern that is a Java class which does get a new serialVersionUID during compilation (if one wasn’t set). Regardless, using serialVersionUID throws a different runtime exception placing you back in the same tight spot and in using type safe enum pattern actually makes life a bit worse.

Should it be a requirement that all enums have a UNKNOWN value, or that every caller should check for null (which would mean the same thing)?

This is an option, but one that I try to shy away from. The reason is that if your enum on the server contains values that the client can actually use than what you’ve actually done is place data that is operational into a static structure. Using an UNKNOWN value would have to retain the value from the enum on the server side so that the client could get at that information. I think my main point of this post is really to address the fact that most enums really shouldn’t be enums unless you can 100% guarentee that you’ve thought of all the possible values and they WILL NOT change in the forseeable future, or ever. Thread state is a good example of a true enum. Countries is an example of a bad enum.

Why would you have Foo be a string? Doesn’t that defeat the whole point of enums (that there are only X valid values allowed)?

This is the tough part. You are using an enum to ensure a constrained set, but that set is in flux. I’d much rather make the objects flyweights that are backed by a database or properties file. This can ensure that bad values aren’t used, but allows client and server to be updated to work with new values without restarting the VM and changing code. There are other solutions like a reloadable resource bundle or the like as well. But, you better make sure to update the clients first and the server second ;)

A few questions:

What (if any) languages are actually good at versioning? Is it always something you have to graft into the language?

Can’t you use the serialVersionUID to determine if a enum has changed (forgive my ignorance, as I haven’t done much with enums)?

Should it be a requirement that all enums have a UNKNOWN value, or that every caller should check for null (which would mean the same thing)?

Why would you have Foo be a string? Doesn’t that defeat the whole point of enums (that there are only X valid values allowed)?