Towards better serialization

[Kevin Bourrillion]

I think the discussion I'm seeing on-list may be ignoring the forest for a
few of its trees. Java's implementation of serialization has been a gaping
wound for a long time, for all the reasons the doc so carefully lays out.
And every framework to support other wire formats has always had to start
from scratch. Isolating how we get data in and out of objects from how we
read and write that data on the wire is self-evidently the right thing to
do, and this looks like a very clean way to do it, and I can find little
fault with it.

I don't know that it's necessary to remove the old serialization. It works
just fine for symmetric serialization (a controlled environment where you
can guarantee the reader and writer use the exact same code). Under that
constraint, it actually delivers on its promise. It's just that it's
dangerous for almost anything else.

The main thing that I have a problem with is `open`. It seems we are
turning 4 visibility levels into a 4x2 matrix (with one cell, `public
open`, being redundant) ... and just because of reflection? This feels
wrong to me. It might be what we need, but I would *really* like to know
that we've exhausted all alternatives. Again, though, this is a tree. The
forest is good.


On Tue, Jun 11, 2019 at 12:21 PM Brian Goetz <brian.goetz at oracle.com> wrote:

> I've posted a document at:
>
>     http://cr.openjdk.java.net/~briangoetz/amber/serialization.html
> <http://cr.openjdk.java.net/~briangoetz/amber/serialization.html>
>
> on an exploration we've been doing to address some of the shortcomings of
> Java serialization, building on other tools that have been (or will be)
> added to the platform.  Rather than attempt to add band-aids on existing
> serialization, it addresses the risks of serialization at their root.  It
> is somewhat of a shift -- it cannot represent all object graphs, and it
> makes some additional work for the author -- but it brings object
> serialization into the light, where it needs to be in order to be safer.
> Comments welcome!
>


-- 
Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20190613/c87eae8e/attachment.html>