river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <nic...@hedhman.org>
Subject Re: OSGi
Date Sat, 04 Feb 2017 09:37:22 GMT
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.


On Sat, Feb 4, 2017 at 3:35 PM, Gregg Wonderly <gergg@cox.net> wrote:

> > On Feb 3, 2017, at 8:43 PM, Niclas Hedhman <niclas@hedhman.org> wrote:
> >
> > On Fri, Feb 3, 2017 at 12:23 PM, Peter <jini@zeus.net.au> wrote:
> >
> >>
> >> No serialization or Remote method invocation framework currently
> supports
> >> OSGi very well, one that works well and can provide security might gain
> a
> >> lot of new interest from that user base.
> >
> >
> > What do you mean by this? Jackson's ObjectMapper doesn't have problems on
> > OSGi. You are formulating the problem wrongly, and if formulated
> correctly,
> > perhaps one realizes why Java Serialization fell out of fashion rather
> > quickly 10-12 years ago, when people realized that code mobility (as done
> > in Java serialization/RMI) caused a lot of problems.
> I’ve seen and heard of many poorly designed pieces of software.  But, the
> serialization for Java has some very easily managed details which can
> trivially allow you to be 100% successful with the use of Serialization.
> I’ve never encountered problems with serialization.  I learned early on
> about using explicit versioning for any serialization format, and then
> providing evolution based changes instead of replacement based changes.  It
> takes some experience and thought for sure.  But, in the end, it’s really
> no different from using JSON, XML or anything else.  The format of what you
> send has to be able to change, the content which must remain in a
> compatible way has to remain accessible in the same way.  I really am
> saddened by the thought that so many people never learn about binary
> structured data in their classes or through materials they might read to
> learn about such things.
> What generally happens is that people forget to design extensibility into
> their data systems, and then end up with all kinds of problems.   Here’s
> some of the rules I always try to follow.
> 1. Remote interfaces should almost always pass non native type objects
> that wrap the data needed.  This will make sure you can seamlessly add more
> data without changing method signatures.
> 2. Always put a serial version id on your serialized classes.  Start with
> 1, and increment it as you make changes by more than just ‘1’.
> 3. When you are going to add a new value, think about how you can make
> that independent of existing serialized data.  For example, when you
> override readObject or writeObject methods, how will you make sure that
> those methods can cast the data for “this” version of the data without
> breaking past or future versions of the object.
> 4. Data values inside of serialized classes should be carefully designed
> so that there is a “not present” value that is in line with a “not
> initialized” value so that you can always insert a new format in between
> those two (see rule 2 above about leaving holes in the versions).
> The purpose of serializing objects is so that you can also send the
> correct code.  If you can’t send the correct code (you are just sending
> JSON), and instead have to figure out how to make your new data compatible
> with code that can’t change, how is that any less complex than designing
> readObject and writeObject implementations that must do the same thing when
> you load an old serialization of an object into a new version of the
> object?  In this case, readObject() needs to be able to inspect the new
> values that the new code uses in readObject and provide initial values for
> them just like the constructor(s) would do if the object was created new.
> I really have never found anything that shipping JSON around makes any
> simpler.   You still have to have a parsable JSON string value.  You still
> have to migrate data formats when their is an old object receive by new
> code.
> The biggest problem of old was people not using an explicit serial version
> id.  Several times, I have had to add an explicit serial version id to old
> code so that it would deserialize correctly into new classes.  Sometimes it
> is hard to do that.  But, that’s not a problem with the system as much as
> it is a lack of understanding or actual neglect in following the design
> standards of the serialization process.
> Gregg
> >
> > IMHO, RMI/Serialization's design is flawed. Mixing too many concerns in
> the
> > same abstraction; sandboxing w/ integration , code mobility, class
> > resolution, versioning and deserialization, with very little hooks to
> > cusomize any or all of these aspects. And these aspects should not have
> > been wrapped into one monolith.
> >
> > Further, I think the only "sane" approach in a OSGi environment is to
> > create a new bundle for the Remote environment, all codebases not part of
> > the API goes into that bundle and that the API is required to be present
> in
> > the OSGi environment a priori. I.e. treat the Remote objects in OSGi as
> it
> > is treated in plain Java; one classloader, one chunk, sort out its own
> > serialization woes. Likewise for the server; treat it as ordinary RMI,
> > without any mumbo-jambo OSGi stuff to be figured out at a
> non-OSGi-running
> > JVM. An important difference is that in OSGi, the BundleClassLoader is
> not
> > (required to be) a URLClassLoader, so the Java serialization's auto
> > annotation of globally reachable URLs won't work, and one need to rely on
> > java.rmi.server.codebase property, but a bundle could watch for loaded
> > bundles and build that up for URLs that can be resolved globally.
> >
> >
> > Cheers
> > --
> > Niclas Hedhman, Software Developer
> > http://polygene.apache.org <http://zest.apache.org> - New Energy for
> Java

Niclas Hedhman, Software Developer
http://polygene.apache.org <http://zest.apache.org> - New Energy for Java

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message