Which Is the Best Alternative for Java Serialization

Which is the best alternative for Java Serialization?

The easiest thing for you to do is still to use serialization, IMO, but put more thought into the serialized form of the classes (which you really ought to do anyway). For instance:

1. Explicitly define the SerialUID.
2. Define your own serialized form where appropriate.

The serialized form is part of the class' API and careful thought should be put into its design.

I won't go into a lot of details, since pretty much everything I have said comes from Effective Java. I'll instead, refer you to it, specifically the chapters about Serialization. It warns you about all the problems you're running into, and provides proper solutions to the problem:

http://www.amazon.com/Effective-Java-2nd-Joshua-Bloch/dp/0321356683

---

With that said, if you're still considering a non-serialization approach, here are a couple:

XML marshalling

As many has pointed out is an option, but I think you'll still run into the same problems with backward compatibility. However, with XML marshalling, you'll hopefully catch these right away, since some frameworks may do some checks for you during initialization.

Conversion to/from YAML

This is an idea I have been toying with, but I really liked the YAML format (at least as a custom toString() format). But really, the only difference for you is that you'd be marshalling to YAML instead of XML. The only benefit is that that YAML is slightly more human readable than XML. The same restrictions apply.

Java serialization alternative with better performance

have a look at kryo.
its much much faster than the built-in serialization mechanism (that writes out a lot of strings and relies heavily on reflection), but a bit harder to use.

edit: R.Moeller below suggested FST, which i've never heard of until now but looks to be both faster than kryo and compatible with java built-in serialization (which should make it even easier to use), so i'd look at that 1st

Is using Serialization a good idea?

Sure there are alternatives to Java serialization: XML (as you've noted); JSON; protobuf; anything else that you'd care to use instead.

All of them will run some risk of incompatible changes. I don't see that there's any magic in the other methods. If you add a new attribute to an object, you've got to deal with "duck typing". If you remove an attribute that's required, all methods will have problems.

Are there good alternatives for serializing enums in Java?

After going back and forth regarding different solutions, I figured a solution based on the suggestion from @GuiSim : one can build a class that contains an enum value. This class can

1. do custom deserialization; thus I can prevent there won't be exceptions during the deserialization process
2. provide simple methods like isValid() and getEnumValue(): the first one tells you if the enum deserialization actually worked; and the second one returns the deserialized enum (or throws an exception)

What could be the alternative of not serializing a value-based class such as LocalDateTime

What the page you are linking to says is

A program may produce unpredictable results if it attempts to
distinguish two references to equal values of a value-based class…

So generally there are no issues with serializing and deserializing objects of such classes. If you serialize, say, a LocalDateTime and deserialize it again, you will get an object that is equal to the first one. That’s generally all you need.

If you serialize two objects with references to the same LocalDateTime, you may get two objects with references to two equal, but distinct LocalDateTime. Or the other way around, if you serialize two objects with references to two different but equal LocalDateTime, they could theoretically come back with references to one and the same object.

What this means, is that after deserialization, unexpected results may come from, for example

if (myLocalDateTime == myOtherLocalDateTime)

You ask

what could be the alternative in this case?

The alternative is: always compare such objects with .equals:

if (myLocalDateTime.equals(myOtherLocalDateTime))

Then you’re safe.

Which SOAP XML object serialization library for Java would you recommend?

I prefer JAX-WS (with JAXB 2.1 databinding) over the other liberaries I've used (JAX-RPC, Axis 1 and 2, but not XFire). The JAXB 2 databinding uses generics, which makes for a pleasant mapping of properties with a maxoccurs > 1. JAX-WS itself is reasonably well documented and provides a reasonably good API. The method and parameter annotations can get a bit out of hand in some cases - XML hell in annotation form. It usually isn't so bad.

One of the nice aspects of the JAX-WS stack is project Metro, which Sun co-developed with Microsoft and interoperates well with the web service support .NET 3.0, going so far as to implement MTOM in a workable fashion.

How does Java's serialization work and when it should be used instead of some other persistence technique?

I would personally try to avoid Java's "built-in" serialization:

• It's not portable to other platforms
• It's not hugely efficient
• It's fragile - getting it to cope with multiple versions of a class is somewhat tricky. Even changing compilers can break serialization unless you're careful.

For details of what the actual bytes mean, see the Java Object Serialization Specification.

There are various alternatives, such as:

• XML and JSON, as you've shown (various XML flavours, of course)
• YAML
• Facebook's Thrift (RPC as well as serialization)
• Google Protocol Buffers
• Hessian (web services as well as serialization)
• Apache Avro
• Your own custom format

(Disclaimer: I work for Google, and I'm doing a port of Protocol Buffers to C# as my 20% project, so clearly I think that's a good bit of technology :)

Cross-platform formats are almost always more restrictive than platform-specific formats for obvious reasons - Protocol Buffers has a pretty limited set of native types, for example - but the interoperability can be incredibly useful. You also need to consider the impact of versioning, with backward and forward compatibility, etc. The text formats are generally hand-editable, but tend to be less efficient in both space and time.

Basically, you need to look at your requirements carefully.

---

Related Topics