> On Feb 4, 2017, at 4:21 AM, 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". > > I fail to understand how JSON or XML changes anything here. > > 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" > > 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.
Yes, it is computationally involved and that can cause some problems with the thread of execution that encounters it. My work around delayed unmarshalling and the notion of never preferred classes are precisely targeting this issue so that you can encounter that “blocking” at the moment you have to. Gregg > > Thanks, > Michal > > Niclas Hedhman wrote: >> Gregg, >> I know that you can manage to "evolve" the binary format if you are >> incredibly careful and not make mistakes. BUT, that seems really hard, >> since EVEN Sun/Oracle state that using Serilazation for "long live objects" >> are highly discouraged. THAT is a sign that it is not nearly as easy as you >> make it sound to be, and it is definitely different from XML/JSON as once >> the working codebase is lost (i.e. either literally lost (yes, I have been >> involved trying to restore that), or modified so much that compatibility >> broke, which happens when serialization is not the primary focus of a >> project) then you are pretty much screwed forever, unlike XML/JSON. >> >> Now, you may say, that is for "long lived serialized states" but we are >> dealing with "short lived" ones. However, in today's architectures and >> platforms, almost no organization manages to keep all parts of a system >> synchronized when it comes to versioning. Different parts of a system is >> upgraded at different rates. And this is essentially the same as "long >> lived objects" --- "uh this was serialized using LibA 1.1, LibB 2.3 and >> JRE 1.4, and we are now at LibA 4.6, LibB 3.1 and Java 8", do you see the >> similarity? If not, then I will not be able to convince you. If you do, >> then ask "why did Sun/Oracle state that long-lived objects with Java >> Serialization was a bad idea?", or were they also clueless on how to do it >> right, which seems to be your actual argument. >> >> And I think (purely speculative) that many people saw exactly this problem >> quite early on, whereas myself I was at the time mostly in relatively small >> confined and controlled environments, where up-to-date was managed. And >> took me much longer to realize the downsides that are inherent. >> >> Cheers >> Niclas >> >> >
