--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/jep-154.md	Sun Apr 01 11:41:55 2012 -0700
@@ -0,0 +1,121 @@
+JEP: 154
+Title: Remove Serialization
+Author: Alan Bateman
+Organization: Oracle
+Created: 2012/4/1
+Type: Feature
+State: Posted
+Exposure: Open
+Component: core/libs
+Scope: SE
+Discussion: core dash libs dash dev at openjdk dot java dot net
+Effort: M
+Duration: L
+Template: 1.0
+Internal-refs: Oracle:jplan:417072696c466f6f6c
+
+
+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](http://www.jcp.org/en/jsr/proposalDetails?id=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](http://www.jcp.org/en/jsr/proposalDetails?id=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