aspose file tools*
The moose likes Architect Certification (SCEA/OCMJEA) and the fly likes Disadvantages of using serialization? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Certification » Architect Certification (SCEA/OCMJEA)
Bookmark "Disadvantages of using serialization?" Watch "Disadvantages of using serialization?" New topic
Author

Disadvantages of using serialization?

Ram Dhan Yadav K
Ranch Hand

Joined: Aug 13, 2001
Posts: 321
Hi,
Are there any disadvantages of using Serializable objects?
Ramdhan YK

Ram Dhan Yadav (SCJP, SCWCD, SCJA-I, IBM EC(483))
"We are what we repeatedly do. Excellence, then, is not an act, but a habit."
prabhu anand inbarajan
Greenhorn

Joined: Dec 21, 2001
Posts: 3
I dont see any disadvantages except the disk io.
the more serializable objects you have in a encompassing class , the more i/o will be and also it violates the principle of encapsulation by serializing private variables. The solution would be to use transient declaration for those which doesnt require serialization.
Originally posted by Ramdhan Kotamaraja:
Hi,
Are there any disadvantages of using Serializable objects?
Ramdhan YK

Santosh Kumar Nayak
Ranch Hand

Joined: Aug 02, 2011
Posts: 95
Disadvantages are :-

1)it breaks the object identity.
2)it should not be ideally used with large sized objects.
Mike Blaszczak
Greenhorn

Joined: Sep 02, 2013
Posts: 22
That seems pretty vague. How large is "large"? How is "large" measured? Member count? Object count? Memory usage? How do we measure the size of an instantiated Java object in bytes?
Paul Clapham
Bartender

Joined: Oct 14, 2005
Posts: 18655
    
    8

Yes, indeed. And beyond that -- what are the potential problems which lead to the "not with large objects" rule and what are the alternatives which should be considered?
Alexander Petrov
Greenhorn

Joined: Dec 18, 2007
Posts: 6
Mike Blaszczak wrote:That seems pretty vague. How large is "large"? How is "large" measured? Member count? Object count? Memory usage? How do we measure the size of an instantiated Java object in bytes?


Thats funny, I was just going to write exactly the same questions "How large is "large"?" when I read your post.
Jayesh A Lalwani
Bartender

Joined: Jan 17, 2008
Posts: 2402
    
  28

The biggest problem with serialization is that it's not backward compatible. If you serialize a object, then change class, you cannot deserialize the object back. You can handle this by either using Externalizable and doing the serialization yourself and build backward compatibility into your externaizable, or seal your classes between releases

That's why serialization is used in communication protocols, not as a storage mechanism.
Alexander Petrov
Greenhorn

Joined: Dec 18, 2007
Posts: 6
Jayesh I kind of agree, but not entirely. First thing is that if you assign a serial version ID manualy and don't let the compiler assign it as long as you don't change the binary footprint of the Class you are free to modify it. I think that if you use externalization you will need to do quite a lot of writing to skipp the class metadata and make the binary formal load independently from the class. So we can conclude that it depends both on the serial version ID and the binary footprint. What I am saying is that I don't see significant advantages to the externalization apart from the smaller binary footprint.
Jayesh A Lalwani
Bartender

Joined: Jan 17, 2008
Posts: 2402
    
  28

Well, if you are storing value objects, I would imagine that most changes would modify the binary footprint
Alexander Petrov
Greenhorn

Joined: Dec 18, 2007
Posts: 6
Wou say is correct. But as I said there are always two sides If you are using Domain Driven Design for example and the rules are contained within your POJOes then , the possibility that you want to change the Rule is higher compared to the posibility that you want to change the representation
Not trying to say you are wrong just that there is more than one side of the coin. And personaly don't think that there is a clearly defined answer for this topic, but in the general case the default serialization wins when the small footprint is not a criteria. After all you get everything just by extending one interface, not bad.
Mike Blaszczak
Greenhorn

Joined: Sep 02, 2013
Posts: 22
What is used for storage, if serialization isn't?
Paul Clapham
Bartender

Joined: Oct 14, 2005
Posts: 18655
    
    8

Mike Blaszczak wrote:What is used for storage, if serialization isn't?


Memory can be used for storage. Disk space can be used for storage. Serialization, on the other hand, is a process which converts an object (or more precisely a network of objects connected by references) into an external form which can later be reconstituted into a new copy of that network. That external form doesn't need to be stored anywhere, either. So I'm confused by that question.
Paul Clapham
Bartender

Joined: Oct 14, 2005
Posts: 18655
    
    8

After re-reading the whole thread it looks to me like Mike Blaszczak was asking about this statement made earlier:

That's why serialization is used in communication protocols, not as a storage mechanism.


It is true in practice that the commonest use of serialization is to convert an object network into bytes so that it can be sent immediately to another Java application which will convert those bytes back to an equivalent network of objects. RMI was designed to take advantage of serialization in this way, and other people have used serialization in the same way to do the same sort of thing in their applications.

As Jayesh said, storing a serialized object is vulnerable to change in the design of the object and its referents. Another problem is that a serialized object is opaque, i.e. other applications can't easily access its contents. However persisting Java objects to external storage is a common requirement, and so there are numerous solutions of the "Java persistence" problem. Commonly they use relational databases, which have numerous advantages, and then you have the "object-relational mapping" problem which has several solutions readily available.
Paul Clapham
Bartender

Joined: Oct 14, 2005
Posts: 18655
    
    8

Alexander Petrov wrote:
Mike Blaszczak wrote:That seems pretty vague. How large is "large"? How is "large" measured? Member count? Object count? Memory usage? How do we measure the size of an instantiated Java object in bytes?


Thats funny, I was just going to write exactly the same questions "How large is "large"?" when I read your post.


Well, remember that we're in a forum about architecture, so we don't need a rule like "A Large object is one whose serialized version requires more than 1 megabyte". A rough rule of thumb would be quite acceptable for an architect. Having said that, though, I can't imagine what such a rule of thumb would look like. (Good thing I'm not writing the architect certification exam.)
Mike Blaszczak
Greenhorn

Joined: Sep 02, 2013
Posts: 22
Paul Clapham wrote:Well, remember that we're in a forum about architecture, so we don't need a rule like "A Large object is one whose serialized version requires more than 1 megabyte". A rough rule of thumb would be quite acceptable for an architect. Having said that, though, I can't imagine what such a rule of thumb would look like. (Good thing I'm not writing the architect certification exam.)
The post I question doesn't even offer a rough rule of thumb. Remember that people need guidelines to make decisions, and an architect who doesn't offer useful guidelines isn't a useful architect.

Paul Clapham wrote:After re-reading the whole thread it looks to me like Mike Blaszczak was asking about this statement made earlier:
Yes, I was. Sorry -- I thought that it was obvious what I wask asking about. I'm well-aware of what "serialization" is, and that memory and disk are examples of volatile and non-volatile storage, and that data structures, file systems, and database management systems are higher-level mechanisms for using such

Paul Clapham wrote:As Jayesh said, storing a serialized object is vulnerable to change in the design of the object and its referents.
His assertion presumes a brittle design of the serialization mechanism.

Paul Clapham wrote:Another problem is that a serialized object is opaque, i.e. other applications can't easily access its contents. However persisting Java objects to external storage is a common requirement, and so there are numerous solutions of the "Java persistence" problem. Commonly they use relational databases, which have numerous advantages, and then you have the "object-relational mapping" problem which has several solutions readily available.
Opacity is only a problem if it is a requirement that other applications be able to read the serialized object. Remember that persistence need not include exchange among its demands.
Dieter Quickfend
Bartender

Joined: Aug 06, 2010
Posts: 543
    
    4

I think we can conclude from this discussion that yes, Serializable has its drawbacks, but whether these drawbacks are meaningful depends on the application.


Oracle Certified Professional: Java SE 6 Programmer && Oracle Certified Expert: (JEE 6 Web Component Developer && JEE 6 EJB Developer)
Mike Blaszczak
Greenhorn

Joined: Sep 02, 2013
Posts: 22
... just like everything else in the world. You'd figure a better answer would be available after twelve years.
Paul Clapham
Bartender

Joined: Oct 14, 2005
Posts: 18655
    
    8

Maybe there's just not a lot of interest in the question.
Mike Blaszczak
Greenhorn

Joined: Sep 02, 2013
Posts: 22
Or, the forum doesn't get much traffic. Since ti's here in the "Architect Certification" section, I assumed it was a question for one of the architect exams ... and that would make it very important. Was I wrong to make such an assumption?
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Disadvantages of using serialization?