Announcement Announcement Module
Collapse
No announcement yet.
serializable vs not Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • serializable vs not

    In the Hibernate documentation, their business object classes are based on "serializable". In the Spring PetClinic sample they are not.

    Who is right and why? And why doesn't the other programmer "get it".

    It appears that serializable's main raison d'Ítre is to protect against updated objects being used with old style data or vice versa.

    Is there anything else that I am missing?

    I have the luxury of starting from scratch. Should I go with serializable objects and a serial number in my data or go with the Spring crowd?

    Ron

  • #2
    Are you basically talking about your Hibernate objects implementing Serializable or not? The auction example that comes with Hibernate doesn't use Serializable.

    Comment


    • #3
      Yes, the Hibernate Objects.
      There is no actual example of the underlying object only the DAO in the Spring manual so it is hard to know what the Spring thinking is, so one can only look at the examples for architectural and design philosophy.

      I hope that the above better explains the rational for asking these questions.

      Who is right and why? And why doesn't the other programmer "get it".

      It appears that serializable's main raison d'Ítre is to protect against updated objects being used with old style data or vice versa.

      Is there anything else that I am missing?

      I have the luxury of starting from scratch. Should I go with serializable objects and a serial number in my data or go with the Spring crowd?

      Comment


      • #4
        To determine if you need an object to be Serializable you need to ask different questions. There is no wrong or right to implement Serializable.

        In a webapplication if you need session replication or session persistence your objects need to be Serializable. The objects are written to disk (or database) and on subsequent request re-read from the disk. It can also depend on some frameworks you use. Spring webflow for example requires that all objects in it's scopes are Serializable, because the state is going to be Serialized on the end of a request.

        So it doesn't depend on if you are going to follow the "Hibernate Filosophy" or the "Spring Crowd" it depends on your architecture and application requirements. If yuo have a Spring application which is clustered and needs session replication, you need Serializable regardless if you are using Spring or not.

        So no one here is right or wrong.

        It appears that serializable's main raison d'Ítre is to protect against updated objects being used with old style data or vice versa.
        Serializable is just a tagging interface, the serialVersionUid is one of the legacy things from java 1.1 in newer versions it isn't needed anymore. Simply said an object which is Serializable may be written to a file system (the whole object will be written) if in the mean time the class changes, you are in trouble because the objects written to file cannot be read with the new(er) version of the class.

        I suggest you read up on Serializable and Object Serialization.

        Comment


        • #5
          Well as I said the Hibernate auction example (that ships with the code), doesn't implement Serializable. The Spring petclinic example doesn't either. Why should you have to implement Serializable? I'm sorry if I'm missing your point! I just don't understand the question.

          edit: only just seen Marten's previous and much better answer. what ever he says goes........
          Last edited by karldmoore; Feb 12th, 2007, 07:27 AM.

          Comment


          • #6
            Originally posted by mdeinum View Post
            To determine if you need an object to be Serializable you need to ask different questions.
            What questions besides the one mentioned below.
            What is the downside of using Serializable?

            Originally posted by mdeinum View Post
            In a webapplication if you need session replication or session persistence your objects need to be Serializable. The objects are written to disk (or database) and on subsequent request re-read from the disk. It can also depend on some frameworks you use. Spring webflow for example requires that all objects in it's scopes are Serializable, because the state is going to be Serialized on the end of a request.
            I certainly do not want to close the door for part of the application being implemented in Spring Webflow, so it looks like I should go with Serializable.
            Originally posted by mdeinum View Post
            Serializable is just a tagging interface, the serialVersionUid is one of the legacy things from java 1.1 in newer versions it isn't needed anymore.
            It does throw a warning in Eclipse if it is missing.
            Originally posted by mdeinum View Post
            I suggest you read up on Serializable and Object Serialization.
            I have read everything that I can find in Hibernate and Spring documentation.
            What else do I need to read?

            Thanks for the explanation. It is a big help.

            It does lead to a few questions but on the whole, I think that I will want to go with Serializable just for the option of Spring Webflow.

            Comment

            Working...
            X