• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Liutauras Vilda
  • Jeanne Boyarsky
  • Devaka Cooray
  • Paul Clapham
Sheriffs:
  • Tim Cooke
  • Knute Snortum
  • Bear Bibeault
Saloon Keepers:
  • Ron McLeod
  • Tim Moores
  • Stephan van Hulst
  • Piet Souris
  • Ganesh Patekar
Bartenders:
  • Frits Walraven
  • Carey Brown
  • Tim Holloway

Why every POJO class in web-app is required to inherit Serializable despite webservices?

 
Ranch Hand
Posts: 214
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I downloaded some Java web projects and noticed that their POJO classes inherit Serializable interface. I know that Serializable interface performs serialization as it converts the Java objects into bytestream but my doubt is, if you are using Web-services then Java objects are going to be converted into JSON data and sent to the client. Then why do you need Serialization in a webapp?

Thanks in advance.
 
Saloon Keeper
Posts: 10308
217
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It's not a given that web applications always send data to the client as XML or JSON. Sometimes you want to send binary data.

Another reason might be that they are using the same classes to persist the data. This is a bad habit of some programmers though, you typically want to separate your persistence layer completely, and not mix in data transfer objects for the front-end.
 
Bartender
Posts: 1148
38
IBM DB2 Netbeans IDE Spring Java
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Technically you're right, you can serialize in Json a non-java-serializable class, for example with Gson or Jackson library.
My two cents (just guessing): maybe the code author thought to store those POJOs in an HttpSession - and this require objects to be serializable.
Another guess is that many times POJOs are treated as Java Beans, so that they must be Serializable.
Moreover, in Java  you got serialization for (near) free, so that many times declaring an Object as Serializable is more an habit that a real need.
 
Arun Singh Raaj
Ranch Hand
Posts: 214
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks for replying.

Does @Transient annotation exclude the specific field while sending the JSON data? or it's specific to only Serialization? Does @Transient work in non-'Serializable' class?
 
Bartender
Posts: 20842
125
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Webapp objects in session scope MUST, per JEE spec, be serializable. One reason is that a webapp server must have the liberty to be able to push the object out to external storage if RAM runs short. Also, it aids in clustering. The Tomcat webapp server will reject any attempt to store an object in session scope if it doesn't implement the Serializable interface.

Likewise ORM Entity model objects MUST (per the EKJB/JPA spec) be serializable. In this case, I'd hope that the reason was obvious.

As far as I know, other POJOs, such as Request Scope objects, do not need to be serializable.

The transient attribute has no meaning on non-serializable objects. It's probably not even worth having the software complain about it.
 
Sheriff
Posts: 21759
102
Eclipse IDE Spring VI Editor Chrome Java Ubuntu Windows
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Claude Moore wrote:Technically you're right, you can serialize in Json a non-java-serializable class, for example with Gson or Jackson library.
Moreover, in Java  you got serialization for (near) free, so that many times declaring an Object as Serializable is more an habit that a real need.


Classic Java serialization is awful, and Oracle knows it; they are working quite hard to replace it. The problem is that it doesn't easily support forward and/or backward compatibility. If you don't define an explicit serialVersionUid, every change to the class will cause a new value to be generated which will break any previously serialized data. If you do define a serialVersionUid explicitly you still can run into problems if you add or remove fields.

Arun Singh Raaj wrote:Thanks for replying.

Does @Transient annotation exclude the specific field while sending the JSON data? or it's specific to only Serialization? Does @Transient work in non-'Serializable' class?


For serializable classes you should use the transient keyword. @Transient doesn't mean anything in that context. For JSON or XML serialization it's also useless because they have their own annotations (@XmlTransient for JAXB, @JsonIgnore for Jackson, etc). For JPA, @javax.persistence.Transient does mean a field or method will not get stored in the database. There's also a java.beans.Transient which I have never used before, but its JavaDoc seems to indicate it's pretty useless unless you're using introspection.
 
Tim Holloway
Bartender
Posts: 20842
125
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Claude Moore wrote:
Moreover, in Java  you got serialization for (near) free, so that many times declaring an Object as Serializable is more an habit that a real need.



Serializable isn't a characteristic that adds functionality to a bean's definition. It's a promise that all of the "important" (non-transient) properties of that bean can be converted to a 1-dimensional (serial) notation and that the essential object can be re-constructed from that 1-dimensional form. It doesn't say anything about the encoding or organization of that form - and as Rob has noted, that has lead to awful consequences in the past. Indeed, an object marked Serializable should be capable of not only being converted to the JVM's internal binary serial format (which is neither documented, nor version-independent), but likewise to XML, YAML, JSON, Greek hexametric poetry, cuneiform or any other mechanism that is amenable to strict conversion in and out of that linear form. OK, maybe Greek and Assyrian translations aren't guaranteed unambiguous, but you get the idea, I hope.

 
Claude Moore
Bartender
Posts: 1148
38
IBM DB2 Netbeans IDE Spring Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Tim Holloway wrote:

Claude Moore wrote:
Moreover, in Java  you got serialization for (near) free, so that many times declaring an Object as Serializable is more an habit that a real need.



Serializable isn't a characteristic that adds functionality to a bean's definition. It's a promise that all of the "important" (non-transient) properties of that bean can be converted to a 1-dimensional (serial) notation and that the essential object can be re-constructed from that 1-dimensional form. It doesn't say anything about the encoding or organization of that form - and as Rob has noted, that has lead to awful consequences in the past. Indeed, an object marked Serializable should be capable of not only being converted to the JVM's internal binary serial format (which is neither documented, nor version-independent), but likewise to XML, YAML, JSON, Greek hexametric poetry, cuneiform or any other mechanism that is amenable to strict conversion in and out of that linear form. OK, maybe Greek and Assyrian translations aren't guaranteed unambiguous, but you get the idea, I hope.



That's absolutely right, but  a Java Bean is by definition a class which implements Serializable interface (according to Oracle definition of a JavaBean).
Maybe the class author wanted to respect JavaBean specification literally, who knows ?
I don't think and I don't mean to say that standard Java serialization is flawless - as Rob noted, Oracle itself is trying to drop it replacing with something more secure and portable, and personally I hope that one day we'll be able to serialize and deserialize any complex object directly in JSON, with JVM
built-in support. But I think that depsite all java serialization could be useful if used well - for example, to exchange data between two Java peers.
 
Tim Holloway
Bartender
Posts: 20842
125
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think that Serializable predates the current definition of JavaBean.

Interfaces are promises that a class instance will support certain functions. Generally these promises are defined via method declarations in the Interface definition (and thus enforced by the compiler), but not always. The java.io.Serializable interface is an example of a more abstract promise. It declares that the class can be converted to 1-dimensional form, but leaves the actual methods and mechanisms to be determined externally. They hedge their bets. The javadocs indicate that to use the actual built-in binary serializer you need to declare certain methods, but those methods are not necessary if, for example, you only serialize to/from XML.
 
Claude Moore
Bartender
Posts: 1148
38
IBM DB2 Netbeans IDE Spring Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Tim Holloway wrote:I think that Serializable predates the current definition of JavaBean.


I just verified and you are right.A Javabean isn't any more required to be declared as Serializable.
I think I need to update my knowledge of the Java language specification
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!