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

Discussion in 'Java' started by Venkat Sadasivam, Mar 24, 2008.

  1. 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
     
    Venkat Sadasivam, Mar 24, 2008
    #1
    1. Advertising

  2. Venkat Sadasivam

    Roedy Green Guest

    On Mon, 24 Mar 2008 07:17:03 -0700 (PDT), Venkat Sadasivam
    <> wrote, quoted or indirectly quoted
    someone who said :

    >
    >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.
    --

    Roedy Green Canadian Mind Products
    The Java Glossary
    http://mindprod.com
     
    Roedy Green, Mar 24, 2008
    #2
    1. Advertising

  3. Venkat Sadasivam

    Lew Guest

    Roedy Green wrote:
    > On Mon, 24 Mar 2008 07:17:03 -0700 (PDT), Venkat Sadasivam
    > <> wrote, quoted or indirectly quoted
    > someone who said :
    >
    >> 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.


    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.

    --
    Lew
     
    Lew, Mar 25, 2008
    #3
  4. Lew wrote:
    > Roedy Green wrote:
    >> On Mon, 24 Mar 2008 07:17:03 -0700 (PDT), Venkat Sadasivam
    >> <> wrote, quoted or indirectly quoted
    >> someone who said :
    >>
    >>> 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.

    >
    > 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
     
    Arne Vajhøj, Mar 26, 2008
    #4
  5. Venkat Sadasivam

    Lew Guest

    Lew wrote:
    >> 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 wrote:
    > 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.

    --
    Lew
     
    Lew, Mar 26, 2008
    #5
  6. Lew wrote:
    > Lew wrote:
    >>> 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 wrote:
    >> Serializable does not have any methods, so there are no "private"
    >> anything that becomes accessible.

    >
    > 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
     
    Arne Vajhøj, Mar 26, 2008
    #6
  7. Venkat Sadasivam

    Lew Guest

    Arne Vajhøj wrote:
    >>> Serializable does not have any methods, so there are no "private"
    >>> anything that becomes accessible.


    Lew wrote:
    >> That is neither true nor relevant.


    Arne Vajhøj wrote:
    > 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.

    --
    Lew
     
    Lew, Mar 26, 2008
    #7
  8. 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
     
    Venkat Sadasivam, Mar 26, 2008
    #8
  9. Arne Vajhøj wrote:
    >
    > 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.
     
    Mike Schilling, Mar 26, 2008
    #9
  10. Venkat Sadasivam

    Lew Guest

    Venkat Sadasivam wrote:
    > 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
     
    Lew, Mar 26, 2008
    #10
  11. Venkat Sadasivam

    Lew Guest

    Mike Schilling wrote:
    > Arne Vajh�j wrote:
    >> 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.


    These things are true of Serializable serialization as well.

    --
    Lew
     
    Lew, Mar 26, 2008
    #11
  12. Lew wrote:
    > Mike Schilling wrote:
    >> Arne Vajh?j wrote:
    >>> 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.

    >
    > 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.
     
    Mike Schilling, Mar 26, 2008
    #12
  13. Venkat Sadasivam

    Lew Guest

    Mike Schilling wrote:
    > 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.

    --
    Lew
     
    Lew, Mar 26, 2008
    #13
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Jimmy
    Replies:
    4
    Views:
    653
    Thomas Hawtin
    Aug 8, 2007
  2. Replies:
    8
    Views:
    3,161
  3. Giles Bowkett
    Replies:
    9
    Views:
    417
    Giles Bowkett
    Dec 17, 2007
  4. Replies:
    1
    Views:
    3,294
    Arne Vajhøj
    Jul 31, 2012
  5. raju dasupally

    java serializable interface

    raju dasupally, Nov 21, 2012, in forum: Java
    Replies:
    0
    Views:
    353
    raju dasupally
    Nov 21, 2012
Loading...

Share This Page