JEP 154: Remove Serialization

Summary

Deprecate, disable, and ultimately remove the Java SE Platform's serialization facility.

Non-Goals

It is not a goal of this proposal to introduce an alternative serialization mechanism.

Motivation

Developers are well aware of the myriad shortcomings of Java's serialization facility. The plan to remove it and its associated APIs in the java.io package was first announced many years ago.

One of the motivations for this change is that the Object Serialization Stream Protocol severely limits performance. The protocol was designed with the assumption that the serialized stream would be transmitted over an unreliable connection. It is for this reason that each object and descriptor is written twice to the stream, to allow the bytes to be compared by the receiver. In severely-degraded environments, e.g., Microsoft Windows machines running the McAfee Antivirus program, the TC_OBJECT constant and associated object data may be written to the serialized stream up to eight times due to timeouts caused by real-time virus scanning. Several attempts have been made to avoid writing duplicate data to the stream but none has been successful due to compatibility issues.

A lesser-known issue, and the main reason that this change has been flagged for several releases, is that the available values for serialVersionUID are running out. Although a serialVersionUID is declared as a long (and so up to 2^64 values are available) it is truncated to a 32-bit value in the class descriptor (TC_CLASSDESC). In early versions of the JDK the serialver tool contacted java.sun.com to reserve serialVersionUID values as needed and this ensured that there would be values available for many generations of future developers. This allocation process was discontinued in Sun's JDK 6 and in all OpenJDK releases due to concerns from various free-software and privacy advocates. It was replaced with a reservation mechanism that allocates a large block of serialVersionUID values for each JDK installation. The result is that the available range of serialVersionUID values has been running out quickly and current predictions are that values will likely overflow and wrap around by the end of 2012. Once this happens it is expected that many applications will start to fail intermittently, throwing InvalidObjectException.

Another motivation to removing serialization is that the transient keyword is slated to be re-allocated to another Java language feature planned for a future release. Details of this language feature will be outlined in a future JEP.

Description

Removing Java Serialization will clearly have some compatibility impact and developers will need time to change their applications.

The proposal is that serialization be removed in a phased manner, as follows.

In a JDK 7 update, possibly update 6, the Serializable, ObjectInputStream, ObjectOutputStream, and associated classes in the java.io package will be deprecated. This will require a corresponding Maintenance Review of the Java SE 7 Platform Specification (JSR 336).

In Java SE 8 these types will be removed and all classes in the platform will be changed so that they no longer implement Serializable. A new VM option, possibly -XX:+EnableSerialization, will be introduced as a compatibility option to re-enable serialization for applications that still require it. The details as to how this option will work require further investigation. One approach is to build two copies of rt.jar, one with the classes that implement Serializable and the other (the default) with classes that do non implement Serializable. As JDK 8 is slated to ship in modular form then it may be possible to ship with two copies of each JDK module. Other approaches, including byte-code instrumentation techniques, will also be explored.

In Java SE 9 the option to enable serialization will be removed.

Risks and Assumptions

Implementation of this proposal may hinder the adoption of Java 8.

There is some chance that the Java SE 8 (JSR 337) Expert Group will object to this plan or, at the very least, revise it significantly.

If the compatibility option to re-enable serialization requires that the JDK ship with two copies of rt.jar (or two copies of the JDK modules) then it may have some impact on the size of the JDK download.

Impact

• Compatibility: High
• Documentation: Medium
• TCK: High
• Twitter: High