The future of Serialization

[Paul Sandoz]

On Aug 9, 2014, at 7:20 PM, Brian Goetz <brian.goetz at Oracle.COM> wrote:

>> I've noticed there's not much interest in improving Serialization on
>> these lists.  This makes me wonder if java Serialization has lost
>> relevance in recent years with the rise of protocol buffers apache
>> thrift and other means of data transfer over byte streams.
> 
> I sense your frustration, but I think you may be reaching the wrong conclusion.  The lack of response is probably not evidence that there's no interest in fixing serialization; its that fixing serialization, with all the constraints that "fix" entails, is just really really hard, and its much easier to complain about it (and even say "let's just get rid of it") than to fix it.
> 
>> Should Serializable eventually be deprecated? Should Serialization be
>> disabled by default? Should a new mechanism be developed? If a new
>> mechanism is developed, what about circular object relationships?
> 
> As I delved into my own explorations of serialization, I started to realize why such a horrible approach was the one that was ultimately chosen; while serialization is horrible and awful and leaky and insecure and complex and brittle, it does address problems like cyclic data structures and independent evolution of subclass and superclass better than the "clean" models.
> 
> My conclusion is, at best, a new mechanism would have to live side-by-side with the old one, since it could only handle 95% of the cases.  It might handle those 95% much better -- more cleanly, securely, and allowing easier schema evolution -- but the hard cases are still there.  Still, reducing the use of the horrible old mechanism may still be a worthy goal, even if it can't be killed outright.
> 


Also many serialization-based libraries use sun.misc.Unsafe or sun.reflect.ReflectionFactory for various reasons (with backup plans if such classes are not available or accessible).

As part to the future of serialization i think we need to evaluate libraries such as XStream and Objenesis  to see what unsafe/internal mechanisms can be replaced by functionally equivalent safe public mechanisms.

I have more questions than answers at the moment with regards to that :-(

Paul.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20140827/59419bc2/signature.asc>