206

The question is in the title. Below I just described some of my thoughts and findings.

When I had a very simple domain model (3 tables without any relations), all my entities did NOT implement the Serializable interface.

But when the domain model became more complex, I got a RuntimeException, saying that one of my entities didn't implement Serializable.

I use Hibernate as a JPA implementation, and I wonder:

  1. Is it a vendor-specific requirement/behavior?
  2. What happens with my serializable entities? Should they be serializable for storing or for transferring?
  3. At which moment it becomes necessary to make my entity serializable?
Vlad Mihalcea
  • 142,745
  • 71
  • 566
  • 911
Roman
  • 64,384
  • 92
  • 238
  • 332

14 Answers14

122

According to JPA Spec:

If an entity instance is to be passed by value as a detached object (e.g., through a remote interface), the entity class must implement the Serializable interface.

"JSR 220: Enterprise JavaBeansTM,Version 3.0 Java Persistence API Version 3.0, Final Release May 2, 2006"

Andrew Tobilko
  • 48,120
  • 14
  • 91
  • 142
Conor
  • 2,419
  • 3
  • 19
  • 18
  • 17
    (+1) looking at the spec is always fruitful – Bozho Jan 07 '10 at 16:57
  • 33
    I fail to see why this has so many upvotes. The OP says that it wasn't required when the model was simpler. Sending the objects remotely via Java serialization would ALWAYS require the objects to be Serializable, regardless of its complexity. Obviously this isn't the OP's use case. – Robin Jun 22 '15 at 14:29
  • 1
    I'm not quite sure about hibernate, but with other JPA providers there are operations which require the provider to make a copy of an entity (object). `Serializable` could be helpful with that, and in the context of persistence more consistent than `Cloneable` for instance. – JimmyB Jul 06 '15 at 10:09
  • 8
    This answer is just an info dump and doesn't at all help someone understand why. – chrips Oct 21 '19 at 17:27
83

You need your entities to be Serializable if you need to transfer them over-the-wire (serialize them to some other representation), store them in http session (which is in turn serialized to hard disk by the servlet container), etc.

Just for the sake of persistence, Serializable is not needed, at least with Hibernate. But it is a best practice to make them Serializable.

Bozho
  • 588,226
  • 146
  • 1,060
  • 1,140
  • 2
    I don't know, maybe my entities are being transferred implicitly somewhere. I use hibernate+spring+jsf and Tomcat. Where in this chain transferring can take place? – Roman Jan 07 '10 at 14:31
  • 1
    @Roman for example the current user (which may be an entity) and all its related entities may end up in the session, which as Bozho says can be serialised to disk by the servlet container. – OrangeDog May 01 '19 at 13:55
  • THIS is the best answer "why and When"! Clear! Thank you – chrips Oct 21 '19 at 17:28
  • 2
    Best practise in Java is **not** to make classes serialisable unless you absolutely must for legacy reasons. See Effective Java by Josh Block. What would make it best practice for JPA? OK this is an old answer, these days the need to transfer objects over the wire or store in an http session should be pretty rare. – dan carter Mar 25 '21 at 01:26
  • 2
    @dancarter - This is utter nonsense and is also a mischaracterisation of Josh Bloch's advice on the topic. Serialization is an essential part of the language and runtime. It is certainly not reserved for the support of "legacy" code. There are many circumstances in which you SHOULD or MUST implement Serializable. You should however NOT do so without good reason and without understanding the consequences. Josh's point is that the language makes it far too easy to implement Serializable without knowing why or how to do so safely. – Dave Aug 10 '21 at 10:14
  • 1
    Regarding the now very old original post and this equally old answer: JPA providers make extensive use of caching both in memory and on secondary storage. For all but the simplest implementations this will require serialization of entities. Second level caches typically are persistent for recovery and/or overflow to disk. JPA providers must also sometimes make "carbon" copies of entities and requiring implementation of the Serializable interface is the most reliable way to support this. – Dave Aug 10 '21 at 10:19
  • 1
    Additionally JPA providers often support distributed and or replicated caches for non-trivial applications deployed to clustered nodes. Transmission of entity state between cluster nodes requires serialization. – Dave Aug 10 '21 at 10:22
  • @Dave I m still a little confused by this statement `"if you need to transfer them over-the-wire"`. Also, another doubt when implementing redis caching on methods inside service layer, why do I need to exclusively implement `Serializable interface` ? – humbleCodes Mar 29 '23 at 09:16
  • Also I failed to understand this phrase `"Serializable Interface is not a requirement unless you need detached entities to be sent over the wire to another tier"`. I couldn't understand that in what scenario will my code be performing the scenario as described above ?? – humbleCodes Mar 29 '23 at 10:27
67

This usually happens if you mix HQL and native SQL queries. In HQL, Hibernate maps the types you pass in to whatever the DB understands. When you run native SQL, then you must do the mapping yourself. If you don't, then the default mapping is to serialize the parameter and send it to the database (in the hope that it does understand it).

Aaron Digulla
  • 321,842
  • 108
  • 597
  • 820
39

According to the hibernate docs, while using @JoinColumn annotation:

It has one more parameters named referencedColumnName. This parameter declares the column in the targeted entity that will be used to the join. Note that when using referencedColumnName to a non primary key column, the associated class has to be Serializable.

Nathan Tuggy
  • 2,237
  • 27
  • 30
  • 38
aman maharjan
  • 491
  • 4
  • 2
  • 2
    Thank you for the explanation. I was using `@JoinColumn` with `refenrecedColumnName` to a non-primary unique column from another table. This was causing `ClassCastException` as hibernate could not serialize the entity class. – Himanshu Dabas Jun 23 '21 at 17:47
34

JPA specification

According to the JPA specification, an entity should implement Serializable only if it needs to be passed from one JVM to another or if the entity is used by a Stateful Session Bean which needs to be passivated by the EJB container.

If an entity instance is to be passed by value as a detached object (e.g., through a remote interface), the entity class must implement the Serializable interface.

Hibernate

Hibernate only requires that entity attributes are Serializable, but not the entity itself.

However, implementing the JPA specification, all the JPA requirements regarding Serializable entities apply to Hibernate as well.

Tomcat

According to Tomcat documentation, the HttpSession attributes also need to be Serializable:

Whenever Apache Tomcat is shut down normally and restarted, or when an application reload is triggered, the standard Manager implementation will attempt to serialize all currently active sessions to a disk file located via the pathname attribute. All such saved sessions will then be deserialized and activated (assuming they have not expired in the mean time) when the application reload is completed.

In order to successfully restore the state of session attributes, all such attributes MUST implement the java.io.Serializable interface.

So, if the entity is stored in the HttpSession, it should implement Serializable.

Kevin Peters
  • 3,314
  • 1
  • 17
  • 38
Vlad Mihalcea
  • 142,745
  • 71
  • 566
  • 911
27

If we just talk about persistence, Serializable is not needed But it is best practice to make the entities Serializable.

If we are exposing domain/entities objects directly exposed to the presentation layer, instead of using DTO , In that case we need to implement Serializable. These domain objects can be stored in HTTPSession for caching/optimization purposes. A http-session can be serialized or clustered. And it is also required for transferring data between JVM-instances.

When we use DTO to decouple persistence layer and service layer, marking the domain objects as Serializable would be counter productive and would violate the “encapsulation”. Then it becomes an anti-pattern.

Composite identifiers

The primary key class must be serializable.

POJO Models

If an entity instance is to be used remotely as a detached object, the entity class must implement the Serializable interface.

Cache
In addition, if you are implementing a clustered second level cache then your entities must be serializable. The identifier has to be Serializable because that’s a JPA requirement since the identifier might be use as the key for a second-level cache entry.

And when we serialize entities make sure to provide explicit serialVersionUID with private access modifier. Because if a serializable class does not explicitly declare a serialVersionUID, then the serialization runtime will calculate a default serialVersionUID value for that class based on various aspects of the class, as described in Java(TM) Object Serialization Specification . Default serialVersionUID computation is highly sensitive to class details that may vary depending on compiler implementations, and can thus result in unexpected InvalidClassExceptions during deserialization.

Ankur Singhal
  • 26,012
  • 16
  • 82
  • 116
  • 3
    for Cache +1. This answer is detailed. It just landed late so the score is not high. – samshers Nov 23 '20 at 14:50
  • 1
    @Ankur " If we are exposing domain/entities objects directly exposed to the presentation layer, instead of using DTO , In that case we need to implement Serializable " this is INCORRECT. According to Joshua Bloch Effective Java "Once an object has been serialized, its encoding can be sent from one VM to another or stored on disk for later deserialization" . In case if presentational layer is Browser(in most cases) , object serialization java inbuilt serialization does not happen, because browser will not understand deserialized stream. – sparrow2 Dec 08 '20 at 16:02
  • DTO object wo serilization works. Is it because all entity internally are serializaed? – Satish Patro Dec 09 '20 at 12:22
8

I believe your problem is related to having a field of a complex type (class) which isn't annotated. In such cases the default handling will be storing the object in its serialized form in the database (which probably isn't what you meant to do) Example:

Class CustomerData {
    int getAge();
    void setAge(int age);
}

@Entity
Class Customer {
  CustomerData getCustomerData();
  void setCustomerData(CustomerData data)
}

In the above case the CustomerData will be saved in a byte array field in the database in its serialized form.

Nathan Hughes
  • 94,330
  • 19
  • 181
  • 276
Avner Levy
  • 6,601
  • 9
  • 53
  • 92
  • This is an interesting one, so as long as CustomerData implements Serializable, when loading a Customer it will be able to deserialize the customerData? – bonapart3 Apr 19 '21 at 12:22
8

To complement the nice answer of Conor who referred to the JSR-317 specifications. Typically, EAR projects consist of an EJB module with the EJBs exposed via a remote interface. In this one case you need to make your entity beans serializable as they are aggregated in the remote EJB and are built to be wired through the network.

A JEE6 war project without CDI: can contain EJB lite backed by non-serializable JPA entities.

A JEE6 war project with CDI: Beans that use session, application, or conversation scope must be serializable, but beans that use request scope do not have to be serializable. Thus the underlying JPA entity beans -if any- would follow the same semantics.

Sym-Sym
  • 3,578
  • 1
  • 29
  • 30
6

Classes must implement Serializable if you want to serialize them. This is not directly related to JPA and the JPA specification does not require that entities are serializable. If Hibernate really complains about this, I suppose it is a Hibernate bug, but I suppose that you directly or indirectly are doing something else with the entities, which require them to be serializable.

jarnbjo
  • 33,923
  • 7
  • 70
  • 94
6

Please refer http://www.adam-bien.com/roller/abien/entry/do_jpa_entities_have_to it says, The implementation of java.io.Serializable is simply required for transfering data via IIOP or JRMP (RMI) between JVM-instances. In case of a pure web application the domain objects are sometimes stored in HTTPSession for caching / optimization purposes. A http-session can be serialized (passivation) or clustered. In both cases all the content have to be Serializable.

Arun K
  • 115
  • 1
  • 2
2
  1. At which moment it becomes necessary to make my entity serializable?

Implementing ehcache with diskstore as second level cache (i.e. using @Cacheable annotation on entity or repository/service method) requires Serializable, otherwise the cache will fail (NotSerializableException) to write the entity to the disk cache.

Michal
  • 2,078
  • 23
  • 36
1

remote hit using postman or ajax or angular js etc....., may cause the repeat cycle with StackOverflow exception with Jackson fasterxml.So, it is better to use serializer.

tamil
  • 11
  • 2
1

when JPA entities are used as parameters or return values by the remote EJB operations

SAR
  • 1,765
  • 3
  • 18
  • 42
0

This is also the error that's thrown when you pass an incorrectly-typed ID as the second param to something like em.find() (i.e. passing the entity itself rather than its ID). I haven't found it yet necessary to actually declare JPA entities serializable--it's not really necessary unless you're using referencedColumnName as described by aman.

Alkanshel
  • 4,198
  • 1
  • 35
  • 54