> On Feb 3, 2017, at 8:43 PM, Niclas Hedhman <nic...@hedhman.org> wrote: > > On Fri, Feb 3, 2017 at 12:23 PM, Peter <j...@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
