Hessian 2.0 versus Java serialization

I think if Hessian 2.0 is to be a drop-in replacement for Java serialization,
it will need to have support for "byte", "short", and "float" data type.
Java 5 support is also required.

If you looked at the meta data class for Hessian, it is obvious that the
overloading rules of Hessian are different than Java. I would focus more
on Java compatibility instead of compression. If you can't drop-in replace
ObjectInputStream, it doesn't matter that Hessian can compress better.

But getting back to compression, when I tried to use Hessian to serialize
Java objects, the repeating emission of identically named class names
popped out at me. I suspect fixing this issue does not require a new syntax.
Just moving the type name to within the list or map structure should do it.

I abandoned Hessian serialization when I hit on an issue with Java 5 enums.
It seems too risky to write custom serializations; I could have spent 2 weeks
debugging various quirkiness that comes up. So I decided to layer
ObjectOutputStream under Hessian. All object arguments and results are
serialized with ObjectOutputStream. A 'j' prefix precedes every such objects.
An exception is prefixed by a 'J'. An ObjectOutputStream reset is performed
at the beginning of every remote procedure call. I am not sure if Hessian
can synchronize the dumping of the object cache as easily.

Thomas Wang
Received on Thu 22 Jun 2006 11:15:10 -0700