CODEWITHSUNDEEP
javaxmlserializationxml-serializationjvm
Debadyuti Maiti
Debadyuti Maiti

Reputation: 1169

Is using Serialization a good idea?

There are several risks regarding Serialization including incompatible changes. If incompatible changes occur in the classes being serialized then we can't de-serialize it even with static final long serialVersionUID field.

So, what's the alternatives of serialization ? XML ? If there's any alternative then is there at all any use of serialization in real world projects ?

Upvotes: 3

Views: 869

Answers (3)

andrew cooke
andrew cooke

Reputation: 46872

you seem to be confusing serialization with data formats - it's probably best to separate them.

there are, broadly, three kinds of serialization:

  1. automated, comprehensive, low-level - this is useful because it can be provided as a service and requires little effort to use. but, by its nature, it is closely related to the internal format used in the language/program - if that changes then de-serialization will be "difficult". typical examples are the "native" serialization provide by java and python; it's useful for short-term snapshots of program state.

  2. automated, restricted, medium-level - typically used for communication/inter-operation. this will not support all features of a language, probably allowing only simple data structures to be saved. if that's sufficient then it's a useful middle ground as it can be automated but is independent of the language's internal format (but not, necessarily, of the program's details). typical examples include protocol buffers, thrift, and json libraries (not json itself, which is a data format...); obviously, this is useful for comms and as ad-hoc data stores.

  3. "hand coded", high level - this requires more work, and will probably save less information, but aims to extract the "important parts" in a way that is independent of the internal format used in the program (or language). examples include docbook or open document (jaxb is rather nice in providing support for close-to-(1) by default, but allowing close-to-(3) with care); this is useful for long-term data archiving and is often associated with "official" specs.

separate from the above is the data format used to encode the serialized data. i am sure you can implement all the above in xml; json tends to be used at (2).

anyway, to answer the question - (1) has the problems you note. if (2) is sufficient, then it is a simple solution (but still suffers from some of the problems of (1) if data structures within the program change); otherwise you need to do the extra work implied by (3).

Upvotes: 2

duffymo
duffymo

Reputation: 309008

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.

Upvotes: 3

ulmangt
ulmangt

Reputation: 5423

The answer depends on your goal. If you're sending data between Java processes, the default Java serialization mechanism may work fine.

However, for storing data, particularly data which humans may want to look at or edit, the Java serialization mechanism is poorly suited.

There are a number of great XML-based java serialization libraries which I greatly prefer when human readable/editable output is required.

Two great ones are: XStream and JAXB

Upvotes: 1

Related Questions