Re: Hessian 2.0 versus Java serialization

On Jun 22, 2006, at 11:15 AM, Thomas Wang wrote:

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

It's not intended to exactly replace Java serialization.

The interop with other languages is important, so it's important to
keep the number of datatypes simple.

In practice, the missing byte and short are generally less important
than you'd guess. If the object is a field, like "byte foo", then
the deserializer can do a (byte) readInt().

The case where Hessian is lossy for Java is when you store Byte
objects into an Object, like an ArrayList. But that can generally be
avoided when the application is designed.

> Java 5 support is also required.

True. I've just added a bug report.

I think the Hessian 1.0 encoding would look like

   M t .. foo.Color
       S .. name
       S .. red

In the compact form, the definition and first enum would look like

   O t .. foo.Color
       x91 -- length = 1
       S .. name
       S .. red

And any additional enums would look like

   o x91 S .. blue

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

I'm not sure I understand. Can you explain more?

> 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'd think that would change the syntax. The new O,o syntax fixes
that problem. It's really nice how compact a second object instance
is. The overhead is only 2 bytes and then the size of the fields.

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

Yep. enums are something we should take responsibility for.

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

If the reset method isn't there, it's easy to add. reset() just
involves clearing a few maps.

-- Scott

>
> Thomas Wang
>
>
>
>
Received on Thu 22 Jun 2006 14:28:38 -0700