On Fri, Jun 26, 2009 at 11:39 PM, Gregg Wonderly<[email protected]> wrote: > As statement of my perspective... > > IBM leads the OSGi thrust, and the bad taste that I got from IBM/Eclipse > doesn't leave me feeling excited about doing anything to "work with" IBM. I > found it to be impossible to "work with" eclipse developers. They insisted > it was their way or the highway.
I am pro-OSGi and anti-Eclipse. I have for long been supporting the people who are outside the Eclipse/Equinox "mentality" and I have very little respect for the 'cave-ins' that happened quite a few years ago now, when Eclipse folks black-mailed OSGi into features that OSGi doesn't need. We now have one more similar player in the space, i.e. SpringSource, which will also be dictating quite a few things in the Alliance-space. That said, one can actually live quite happily with OSGi, without paying much attention to what Eclipse/IBM are doing. Apache Felix project is a rich eco-system of OSGi tools and components, including probably the best framework implementation (seen from a maintenance, code-size, stability point of view), and I am also the founder of the "Pax project" at http://wiki.ops4j.org where we create platform-agnostic tools, according to specs instead of incidental trial-error methods. > I am interested in simple software assembly techniques. I am interested in > manageable software systems. Currently, I have no problems getting all of > this out of using Jini and the power of the Java ".jar" mechanisms and > dynamic class loading features of the language. Well, one thing that I always opposed was the opaqueness of the RMI classloader mechanism. It is very unclear how the RMI classloader really works, when classes are dropped and reloaded and what not. IMHO, it is a fluffy model, where one more or less code incidentally. > OSGi from the outside doesn't seem to be "adding" anything to the features > that I need. If you don't want modularization and a promised of module reload in runtime, then I guess there are many system to choose among. > I currently use netbeans, and not eclipse. I currently don't > have a software development system nor a server deployment system based on > OSGi. So, I don't have an easy road to using, trying or developing in the > OSGi "way". Uhhh... You don't need Eclipse. I have not used Eclipse for OSGi development ever. The OSGi specific plugins, known as the Plugin Development Environment, is a buggy piece of shit that for years didn't even comply to the OSGi spec. Many people I know, who uses Eclipse, don't use the OSGi features, just plain JDT. Personally I am on IDEA and rely heavily on Pax and Felix tools to get the job done. > The divisions in systems that developments like OSGi create, are not near as > helpful as they could be if OSGi developers would snuggle up with others in > the industry already doing such things. The problem is that OSGi should have been adopted by Sun for the JVM back in 1998/1999, to provide a rich and deterministic classloading model, and everything built on top. Now, that didn't happen and the OSGi community is trying to slide OSGi in *under* existing technologies with varying degree. Some applications and subsystems are just making too much assumptions of the Java environment (the J2EE classloader hierarchies, only unload if JVM stops, rely on OS cleanup of resources and what not) and will break when running in OSGi environment. > From my perspective, the lack of IBM/OSGi knocking on the door, and the lack > of there being netbeans plugins and other more "ever present" OSGi "stuff" > visible in day-to-day Java news, really tells me that IBM is once again, > like Eclipse, on the path of "Our way or the highway", trying to not work > with anyone else. NIH seems to be the name of the game, and they will either > steam roll everyone into submission, or they will fail because such a huge > wall gets built up around them, that they can't get through. That is a strawman. Eclipse didn't invent OSGi. Eclipse/IBM put very strong demands on the OSGi Alliance on new features in the Release 4.0 specification, otherwise they wouldn't adopt OSGi. Some of those features (e.g multiple versions of the same classes) were good, whereas I think others are just bad (RequiredBundle, Fragments) but was said to be required to allow reasonable effort for converting Eclipse to OSGi. The NIH argument is IMHO more prevalent in Sun, who insisted on JSR-277 until recently, which overlaps partially with OSGi, especially the bits that were moved to JSR-294, which we may live with whether you Gregg like it or not. OSGi is at least an optional choice at the moment, and I would like it to continue that way. > The absolute panic that the Java community was in when it looked like IBM > might buy Sun, I believe, speaks directly toward similar feelings, to mine, > being present elsewhere. I am not sure that Oracle is any better for Java than IBM would have been. Oracle has in-principle decisions to port all Java applications in-house to OSGi, and more importantly to the Eclipse eco-system. Oracle is probably the strongest OSGi Alliance member from a "work performed" point of view, especially since BEA is now part of Oracle. A large portion of the 4.2 release is Oracle driven. > I'm not saying that I should have these feelings, but I'm just laying my > biases out so that it is clear where I'm coming from. Yeah, I know that, but thanks for venting the lungs again. I mean this is not the first time we have discussed this topic. But I honestly think that the train has already left the station. OSGi 4.2 includes remote services, and is IMHO a fairly poor specification, coming from a SCA/SDO/SOAP angle and no lessons learnt from Jini and other network fault tolerant systems. Time will tell how well this will work in reality. Jini/River seems to have fallen into a specialty niche, and perhaps that is just as fine. Remove the pretense and start get work done. Comparison; The Apache Etch project is a platform independent RPC system, which has very specific goals of small footprint, multiple-languages and so on, with an extremely small community. Yet, they are active and pushing the project forward and I would expect graduate sooner rather than later. Apache is a place where it is enough for a handful of individuals doing the work with zero users, but Jini probably has 100s and maybe 1000s of people using it in critical applications. The user base is comparatively large, but progress on the development front is a lot slower. Anyway, Sam, I don't think there is any point any more to try and forge a collaboration between OSGi and Jini. OSGi folks thinks that Jini's service property matching is too simple and that the overhead is too complicated, whereas Jini folks pretty much think like Gregg, OSGi is complicated and brings little to the table. Cheers -- Niclas Hedhman, Software Developer http://www.qi4j.org - New Energy for Java I live here; http://tinyurl.com/2qq9er I work here; http://tinyurl.com/2ymelc I relax here; http://tinyurl.com/2cgsug
