Tips: What is the magic Serializable interface does in Java?

[Venkat Sadasivam]

Most of you might know that serialization is required when you want to
do some I/O operation.

Why not all objects are by default Serializable?

Read the below page to understand the design consideration behind the
serialization.
http://venkatsadasi vam.wordpress. com/2008/ 01/27/what- is-the-magic-
serializable- interface- does-in-java/

- Venkat

 

[Roedy Green]

Why not all objects are by default Serializable?

because it puts restrictions on the object, eg. writing code to
recover transient fields. Some objects, e.g. ones controlling
physical devices or that have OS handles are not going to be
serialisable. It would be lie to claim they were.

 

[Lew]

because it puts restrictions on the object, eg. writing code to
recover transient fields. Some objects, e.g. ones controlling
physical devices or that have OS handles are not going to be
serialisable. It would be lie to claim they were.

Furthermore, serialization imposes an additional public interface on a class,
one which circumvents the usual protections of accessibility (e.g.,
'private'). This is a huge development and maintenance responsibility on a
class, as is maintaining serializability between successive API versions.
What a PITA that would be for a class that would never need it.

 

[Arne Vajhøj]

Furthermore, serialization imposes an additional public interface on a
class, one which circumvents the usual protections of accessibility
(e.g., 'private'). This is a huge development and maintenance
responsibility on a class, as is maintaining serializability between
successive API versions. What a PITA that would be for a class that
would never need it.

Serializable does not have any methods, so there are no "private"
anything that becomes accessible.

Arne

 

[Lew]

Serializable does not have any methods, so there are no "private"
anything that becomes accessible.

That is neither true nor relevant. Serialization of a class makes the private
members of that class, whatever they may be, accessible through the
serialization / deserialization mechanism itself.

Serialization involves many methods that are not part of the Serializable
interface, such as readObject() for example.
<http://java.sun.com/javase/6/docs/api/java/io/Serializable.html>

Clever use of these mechanisms can allow a malicious programmer to write a
class that will crack the private members of a serialized object, unless the
class's author took great care to prevent it.

Read Joshua Bloch's excellent /Effective Java/ for details.

 

[Arne Vajhøj]

That is neither true nor relevant.

Not true ? What public methods does Serializable have ? (I need to
update my Java Docs !)

Serialization of a class makes the
private members of that class, whatever they may be, accessible through
the serialization / deserialization mechanism itself.

I see your point.

I don't consider that "circumvents the usual protections of
accessibility" because it is not really a public/private issue.

Persisting object to disk via serialization is usually a bad idea
because of the risk of incompatible changes to the class. Public
or private does not matter.

XML serialization is better because worst the XML files can be
edited (manually or programmatic).

Arne

 

[Lew]

Not true ? What public methods does Serializable have ? (I need to
update my Java Docs !)

The evaluation was for the conclusion, not for the premise. To be more
precise, I could have said, "That conclusion does not follow from the premise,
nor is it relevant." However, it seemed at the time more circumlocutory than
was needful.

 

[Venkat Sadasivam]

I don't agree with Roedy Green and Lew comments.

The complete serialization logic/code present in ObjectInputStream and
ObjectOutputStream. By including "implements Serializable" code
doesn't cause any performance overhead.

- Venkat

 

[Mike Schilling]

Persisting object to disk via serialization is usually a bad idea
because of the risk of incompatible changes to the class. Public
or private does not matter.

XML serialization is better because worst the XML files can be
edited (manually or programmatic).

Also because it gives the programmer more control over what's
persisted. You can design the bean properties of a serializeable
class to contain precisely what you want. And if need be, you can
completely re-implement the class while keeping the same set of
properties.

 

[Lew]

I don't agree with Roedy Green and Lew comments.

The complete serialization logic/code present in ObjectInputStream and
ObjectOutputStream. By including "implements Serializable" code
doesn't cause any performance overhead.

I never claimed a performance overhead, I claimed a maintenance overhead and a
security risk. These things are truth; it's inherent in the nature of
serialization. Agreement is moot.

 

[Lew]

Also because it gives the programmer more control over what's
persisted. You can design the bean properties of a serializeable
class to contain precisely what you want. And if need be, you can
completely re-implement the class while keeping the same set of
properties.

These things are true of Serializable serialization as well.

 

[Mike Schilling]

These things are true of Serializable serialization as well.

Much harder to accomplish there, though. The real problem is how
seductive it is to let all of the class's fields be serialized (with
perhaps a few obviously transient ones marked as such), and not
realize until you need to modify the class significantly just how
screwed you are.

 

[Lew]

The real problem is how
seductive it is to let all of the class's fields be serialized (with
perhaps a few obviously transient ones marked as such), and not
realize until you need to modify the class significantly just how
screwed you are.

Yes! This is the danger of Serializable - it is a heavy responsibility. That
was my point in the first place.