Is it safe to use bytecode enhancement techniques on classes that might be serialized and why?

Question

I haven't tried this yet, but it seems risky. The case I'm thinking of is instrumenting simple VO classes with JiBX. These VOs are going to be serialized over AMF and possibly other schemes. Can anyone confirm or deny my suspicions that doing behind-the-back stuff like bytecode enhancement might mess something up in general, and provide some background information as to why? Also, I'm interested in the specific case of JiBX.

Alforja

Answer 1

Behind the scenes, serialization uses reflection. Your bytecode manipulation is presumably adding fields. So, unless you mark these fields as transient, they will get serialised just like normal fields.

So, provided you have performed the same bytecode manipulation on both sides, you'll be fine.

If you haven't you'll need to read the serialisation documentation to understand how the backwards compatibility features work. Essentially, I think you can send fields that aren't expected by the receiver and you're fine; and you can miss out fields and they'll get their default values on the receiving end. But you should check this in the spec!

If you're just adding methods, then they have no effect on serialisation, unless they are things like readResolve(), etc. which are specifically used by the serialisation mechanism.

Possibly

+1 for pointing out the KISS approach of just enhancing on both sides. Definitely what I'd try first. – Nealson

Answer 2

Adding/changing/removing public or protected fields or methods to a class will affect it's ability to be deserialized. As will adding interfaces. These are used among other things to generate a serialVersionUID which is written to the stream as part of the serialization process. If the serialVersionUID of the class doesn't match the loaded class during deserialization, then it will fail.

If you explicitly set the serialVersionUID in your class definition you can get by this. You may want to implement readObject and writeObject as well.

In the extreme case you can implement Externalizable and have full control of all serialization of the object.

Absolute worst case scenario (though incredibly useful in some situations) is to implement writeReplace on a complex object to swap it out with a sort of simpler value object in serialization. Then in deserialization the simpler value object can implement readResolve to either rebuild or locate the complex object on the other side. It's rare when you need to pull that out, but awfully fun when you do.

Nealson

+1 for serialVersionUID. I forgot about that. If you don't provide one it's calculated at runtime, which will potentially impact the ability to move objects around. – Possibly