Details
-
JEP
-
Resolution: Withdrawn
-
P4
-
None
-
None
-
Alan Bateman
-
Feature
-
Open
-
SE
-
-
M
-
L
-
154
Description
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