 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / March 2008Tips: What is the magic Serializable interface does in Java?
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 On Mon, 24 Mar 2008 07:17:03 -0700 (PDT), Venkat Sadasivam <venkatachalam.sadasivam@gmail.com> 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.  SignatureRoedy Green Canadian Mind Products The Java Glossary http://mindprod.com > On Mon, 24 Mar 2008 07:17:03 -0700 (PDT), Venkat Sadasivam > <venkatachalam.sadasivam@gmail.com> wrote, quoted or indirectly quoted [quoted text clipped - 6 lines] > 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. SignatureLew >> On Mon, 24 Mar 2008 07:17:03 -0700 (PDT), Venkat Sadasivam >> <venkatachalam.sadasivam@gmail.com> wrote, quoted or indirectly quoted [quoted text clipped - 13 lines] > 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 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. > 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. SignatureLew > Lew wrote: >>> Furthermore, serialization imposes an additional public interface on [quoted text clipped - 8 lines] > > 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 >>> Serializable does not have any methods, so there are no "private" >>> anything that becomes accessible. Lew wrote: >> That is neither true nor relevant. > 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. SignatureLew 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 > 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. SignatureLew > 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. > Arne Vajh�j wrote: >> Persisting object to disk via serialization is usually a bad idea [quoted text clipped - 9 lines] > completely re-implement the class while keeping the same set of > properties. These things are true of Serializable serialization as well. SignatureLew >> Arne Vajh?j wrote: >>> Persisting object to disk via serialization is usually a bad idea [quoted text clipped - 11 lines] > > 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. > 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. SignatureLew Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.