JEP 154: Remove Serialization
|Status||Closed / Withdrawn|
|Discussion||core dash libs dash dev at openjdk dot java dot net|
|Endorsed by||Brian Goetz|
Deprecate, disable, and ultimately remove the Java SE Platform's serialization facility.
It is not a goal of this proposal to introduce an alternative serialization mechanism.
Developers are well aware of the myriad shortcomings of Java's serialization
facility. The plan to remove it and its associated APIs in the
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
A lesser-known issue, and the main reason that this change has been flagged for
several releases, is that the available values for
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
TC_CLASSDESC). In early versions of the JDK the
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
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
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.
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
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
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,
-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
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.
- Compatibility: High
- Documentation: Medium
- TCK: High
- Twitter: High