--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/jep-187.md	Mon Jan 13 16:26:37 2014 -0800
@@ -0,0 +1,104 @@
+JEP: 187
+Title: Serialization 2.0
+Author: Brian Goetz
+Organization: Oracle
+Created: 2013/6/20
+Type: Research
+State: Posted
+Exposure: Open
+Component: core/lang
+Discussion: core dash libs dash dev at openjdk dot java dot net
+Start: 2013/Q3
+Effort: M
+Duration: M
+Template: 1.0
+
+
+Summary
+-------
+
+Java serialization, while useful, presents many challenges for code
+safety, maintainability, and compatibility.  It may be possible to
+restructure serialization so that it is explicit, while still mostly
+unintrusive, which would eliminate many current defects.
+
+
+Goals
+-----
+
+This is a _research JEP_.  The sole goal of this JEP is to explore the
+design space sufficiently to be able to propose a feature JEP (or
+recommend that the feature not be pursued.)
+
+
+Non-Goals
+---------
+
+It is not a goal of this research JEP to produce a production-ready
+implementation or specification.
+
+
+Success Metrics
+---------------
+
+This research JEP will be judged successful if it produces a design that
+we wish to move forward to a feature JEP, or else certainty that we do
+not wish to proceed with this feature.
+
+
+Motivation
+----------
+
+A more flexible serialization mechanism will reduce errors and improve
+maintainability of Java classes.  A more secure serialization mechanism
+will reduce the attack surface of Java applications.
+
+
+Description
+-----------
+
+Serialization, as currently specified, undermines the fundamental
+object-oriented notion that a constructor can enforce that objects are
+created with their representational invariants established.  Because
+serialization is implemented at the representation level, this basic
+mechanism is bypassed, allowing objects to be created that do not respect
+the invariants intended by the developer.  A more explicit serialization
+mechanism would also allow developers to directly express design intent
+for schema evolution.
+
+The current design of serialization poses many hazards for developers:
+
+  - Objects can be maliciously created that do not respect their
+    representational invariants;
+
+  - Even in the absence of maliciously constructed bytestreams, old
+    serialized instances may still not be seen to respect the invariants
+    in the current version of the code, which means that one cannot
+    reason about representational invariants of runtime instances by
+    reading the source code only for the current version;
+
+  - The mechanisms for influencing serialization and deserialization all
+    involve "magic" methods (like readResolve) or fields (like
+    serialVersionUID);
+
+  - Evolving or refactoring a serializable class is often very difficult;
+    and, finally,
+
+  - Developers are often forced to choose between serializability and
+    immutability, since final fields cannot be written from methods like
+    readObject().
+
+The root cause of all of these problems was the desire to make
+serialization transparent, and therefore "magic".  If deserialization
+were more explicitly represented in the programming model, then
+deserialization could proceed through a constructor-like mechanism, which
+would allow an opportunity to check or reestablish invariants, as well as
+explicitly model for incorporating schema evolution.
+
+Issues to be explored by this effort:
+
+  - Feasibility of compatibly evolving serialization through explicit 
+    deserialization constructors;
+  - Compatibility with existing serialized objects;
+  - Migration concerns and tooling options; and
+  - Interactions with modularity.