see below On Sat, Feb 4, 2017 at 6:21 PM, "Michał Kłeczek (XPro Sp. z o. o.)" < michal.klec...@xpro.biz> wrote: > Once you transfer the code with your data - the issue of code version synchronization disappears, doesn't it? > It also makes the wire data format irrelevant. At least for "short lived serialized states".
Only works if you have no exchange with the environment it is executing. And this is where "sandboxing" concern kicks in. What is the sandbox? In a web browser they try to define it to DOM + handful of other well-defined objects. In case of Java Serialization, it is all classes reachable from the loading classloader. And I think Gregg is trying to argue that if one is very prudent, one need to manage this well. > I fail to understand how JSON or XML changes anything here. It doesn't. It makes the issues more visible, and more easy to recover when something goes wrong. Java Serialization is sold "too generic" and hence abused by everyone (myself included) and we (except Gregg and other gurus) get burned badly somewhere along the way. > In the end all of the arguments against Java Object Serialization boil down to: > "It is easy to use but if not used carefully it will bite you - so it is too easy to use" Well, kind of... If you ever need to deserialize a serialVersionUid=1 with a codebase where it is now serialVersionUid != 1, I wouldn't call it "easy to use" anymore. Back in the days when I used this stuff heavily, I ended up never change serialVersionUid. If I needed to refactor it enough to loose compatibility, I would create a new class and make an adapter. > What I do not like about Java Object Serialization has nothing to do with the format of persistent data > but rather with the APIs - it is inherently blocking by design. I am not sure I understand what you mean by that. Cheers -- Niclas Hedhman, Software Developer http://polygene.apache.org - New Energy for Java
