CODEWITHSUNDEEP
javaserializationjakarta-eewildflysonarlint
Hannes Schneidermayer
Hannes Schneidermayer

Reputation: 5727

Is Serialization still used anywhere in Java by any servers, frameworks or J2EE itself?

There is this Sonar rule called Fields in a “Serializable” class should either be transient or serializable. It comes up when you add a non-serializable field to your class. The rule states:

For instance, under load, most J2EE application frameworks flush objects to disk, and an allegedly Serializable object with non-transient, non-serializable data members could cause program crashes, and open the door to attackers.

This sounds outdated to me. In Effective Java 3rd Edition it is stated that Serialization is not relevant, when developing new software. Also, Removing Serialization from Java Is a 'Long-Term Goal' at Oracle. The Java chief architekt himself, Mark Reinhold, stated

„Serialization was a horrible mistake in 1997.“

The question, if the Spring framework may flush objects, was already asked on here:

So I ask the question: Do any modern application servers, frameworks or the J2EE implementation itself (especially Java components that interact with CDI, EJB, JPA) flush objects to disk under heavy load?

Or is this statement outdated?

Upvotes: 4

Views: 1021

Answers (1)

GeertPt
GeertPt

Reputation: 17846

TL;DR

If you're not implementing a distributable web application, you do not enable session persistence, and you only use in-memory caches, you might get away without needing Serializable anywhere.

Explanation

For session replication, Java Serialization is still a must for the latest Servlet Specification: https://jakarta.ee/specifications/servlet/5.0/jakarta-servlet-spec-5.0.html#distributed-environments

A common usecase is if you have multiple servers behind a load balancer, and you login on one server, you get a JSESSIONID cookie. If the load balancer sends you to a different server for the next request, your login attributes and other session-scoped attributes will be serialized and replicated on the new server, so your JSESSIONID is still valid there.

Another usecase where you need Serialization for your session-scoped attributes, is when the application server decides to swap sessions to disk. For e.g. Tomcat 8, this can be configured to activate when there are too many sessions to keep in memory, or when the server is restarted, and you want to keep the sessions alive. See https://tomcat.apache.org/tomcat-9.0-doc/config/manager.html

Every Servlet-5.0 compatible application server must support Serializable objects in Http Sessions by default for these kinds of usecases.

For some servers, this can be tweaked or overridden by using e.g. Jackson-JSON serialization or something similar. See e.g. How to use jackson instead of JdkSerializationRedisSerializer in spring

Another common usecase is caching. This is used to keep objects accessible as fast as possible, ideally in memory, but possibly temporarily offloaded to disk or to an external cache server. There is a standard API for it (JSR-107) that explicitly chose not to require Serializable objects, but most implementations, still use java Serialization for the offloading part as a default.

You can again tweak these to support other serialization mechanisms, e.g. for ehcache: https://www.ehcache.org/documentation/3.8/serializers-copiers.html

Upvotes: 10

Related Questions