1

How does serialization tool(i.e. hessian) deserialize a class of different version with the same serialVersionUID? In most cases, it can skip those unknown(not found in class loader) fields and keep compatible. But last time, I tried appending a new field of Map<String, Object>, put some unknown object into the map, then it threw a ClassNotFoundException.

  • Why can't skip the map like the others?
  • Is it a problem associated with the tool's implementation or serialization mechanism?
Anderson
  • 2,496
  • 1
  • 27
  • 41
  • I try it again, find that hessian transforms the unknown type to a `Hashmap` without throwing exceptions. But for `Class` instance, `Class` is a well-known type, so it starts transforming and throws a `ClassNotFoundException` since `T` is unknown. – Anderson Dec 02 '15 at 06:49

1 Answers1

1

This would depend on the tool itself. serialVersionUID is intended for use by Java's built-in serializer (ObjectOutputStream) which, as best I can tell from reading the Hessian source, is not used by Hessian.

For Hessian specifically, the best source I can find which mentions these kinds of changes is this email:

At least for Hessian, it's best to think of versioning as a set of types of changes that can be handled.

Specifically Hessian can manage the following kinds of changes: 1) if you add or drop a field, the side that doesn't understand the field will ignore it. 2) some field type changes are possible, if Hessian can convert (e.g. int to long) 3) there's some flexibility on map(bean) types, depending on how much information Hessian has (which is a reason to prefer concrete types.)

So, if the sender sends an untyped map {"field1", 10} and the target is known to be MyValue { int field1; }, then Hessian can map the fields.

But it cannot manage things like: 1) field name changes (the data will be dropped). 2) class name changes where the target is underdefined, like Object field1. If you send a MyValue2 as the new field1, when the previous version was MyValue1, Hessian can't make that automatic transition. (But as with #3 above, a "MyValue2 field1" would give Hessian enough information to translate.) 3) class splits, e.g. creating a subclass and pushing some fields into it.
4) map to list or list to map changes.

Basically, I don't think Hessian intends to support unknown types in maps.

Pace
  • 41,875
  • 13
  • 113
  • 156
  • Thanks a lot! But the answer doesn't mention why it can't skip the `Map` field since it matches case 1) ? – Anderson Apr 28 '15 at 03:04
  • An item in a map is not a field in Java. Case one is specifically talking about instances of a "type". A "type" in Hessian is a Class in Java. So case 1 would only apply to unknown fields. A HashMap in Java is an "untyped map" in Hessian terminology. – Pace Apr 28 '15 at 04:03