On Aug 9, 2014, at 7:20 PM, Brian Goetz <brian.go...@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.
signature.asc
Description: Message signed with OpenPGP using GPGMail
