techblog 

Here at Nominet we use Hessian to build our Java middle-tier services. We’ve been using version 3.0.20 for a while and, once you get used to its idiosyncrasies, it’s pretty workable and stable.

Yesterday I tried to update to the latest version, 3.1.3. Suddenly all hell broke loose. A bunch of domain entity objects we’ve been persisting through Hibernate stopped deserialising cleanly at the Java client end. A little debugging revealed that:

• Instances of java.sql.Timestamp would drift by a few seconds from their transmitted version. We’d been using just such fields along with a @Version annotation to provide optimistic locking for Hibernate-managed entities. Lots of StaleObjectStateExceptions get thrown.

“No problem” I thought, “they’re just there because we haven’t moved them over to cleaner, less coupled Integer versioning yet. Refactor!”. Half an hour of refactoring class and table definitions later, and the local unit tests pass again. Back to service-level tests:

• Deserialisation now fails for a couple of alternating reasons, each of which throws a HessianFieldException:
  • Enumerations randomly fail to deserialise, complaining that they couldn’t be assigned from HashSets;
  • Sets of enumerations also fail, with a root IndexOutOfBoundsException from an ArrayList.

At this point I gave up and reverted to the previous version of the library. Another developer here also had the same problems with the updated version, so I think that for now we’ll be sticking with the tried and trusted version 3.0.20. Just because a new library is there doesn’t mean you have to upgrade straight away, or even at all.

Having said that, if anyone can shed any light on these problems it would be very much appreciated…