No, you don't have to use OSGi to write modular software. Modularity is just a concept you can implement in many was.
Dependency injection is another tool and it does help modularity in the implementation of your code by allowing to decouple interfaces from implementations, but it does not in any way offer you modularity in the architectural point of view. You can use DI with or without OSGI with equal ease. Build systems can do only so much for modularity. More often than not I find people tend to say they build modular systems when in reality they simply chop up a big monolithic application into few separate interdependant projects and stil deploy the whole enchilada. Maven and Gradle helps quite a bit here, but only if you use them wisely, which is still a rare thing to behold. I find OSGi helps me because it enforces same rigid class visibility on me both, in development time as well as at runtime. It is uncomfortable as hell to *really* think about things like separation of concerns or package visibility or defining explicit module dependencies when all you've used to do so far is slapping few classes into a jar and calling it a module. Sure, former is more arduous work - you have to actually THINK about these things you've never actually really thought of before - sure, you might think you did, but in reality it was just so breaf and abstract, you might just as well not have. But all that hard work pays off when you start SEEING the actual dependencies and you can start reasoning about it. Hell, you can write programs that can reason about dependencies of your modules. Another thing people are starting to see and get scared is the explosion of bundles/modules. When before you would have two jars you would likely see five or even six bundles. You would have your two API modules and two implementations of these API's and then you would have one or two "bridge" modules that make use of both API's. It tends to scare people. The dependencies are suddenly out in the open and in your face. And it scares people. In it's simplest form, OSGi bundles are nothing more than jar files with some special metadata in their MANIFEST.MF file. It does not get simpler than that. You've actually got some pretty nice tools for generating that metadata in your jar manifest like Bnd <http://www.aqute.biz/Bnd/Bnd> and Bundler <http://www.dynamicjava.org/projects/bundler>. Beyond this, there is the dynamic lifecycle management of bundles in the runtime, OSGi Service registry and that warm fuzzy feeling that you get when you know that your runtime and your development time environments are actually pretty much same. You do not have to use any of the extra runtime features if all you provide is a general purpose library like Log4j or JodaTime or Apache Commons or Google Guava. And you can afford to ignore this even when writing vertical applications relying only on the libraries in your dependancies as before. When you use those advanced features of OSGi however, you need to pay attantion to some principal premises and this is where true complexity comes into play. Due to the highly dynamic nature of OSGi you need to be aware that services you are using may at any point in time go away. You can still opt to ignore this notion if you are absolutely certain that your environment has no need for hot-deployable services and you can tolerate some downtime for the duration of the upgrade. There are of cours also some things you can not do that are easy in classpath based world where all the classes are essentially in one giant soup of a classloader and every class is implicitly visible to every other class. Hence problems and difficulties with frameworks heavy on dynamic reflection like Hibernate or Spring. Punching holes into the bundle visibility encapsulation like Eclipse-BuddyLoading help with visibility but introduce possibilities for sneaky classloader deadlocks that manifest themselves in a most bizarre and inconvenient moments. All in all - I would not call OSGi as complex as it is made out to be. I would go as far as to compare the complexity of the OSGi to the complexity of Scala. Both are arguably complex beasts, but the main complexity is in accepting their differences and learning new concepts. Once you can do that, there is some inherent complexity of solving real world problems in a idiomatic way, but that is what we get paid for... :) Incidentally, Scala standard libraries are also annotated with OSGi metadata, making them OSGi bundles. :) teisipäev, 5. juuli 2011 18:53.31 UTC+3 kirjutas phil swenson: > > you don't have to use OSGi to write modular software..... > > and easier, less risky approach is to use dependency injection enforce > your module breakouts with a decent build system (gradle). This gets > you most of the way w/o out all the tooling and testing headaches. > > On Mon, Jul 4, 2011 at 9:08 AM, Roland Tepp <[email protected]> wrote: > > Well, all the opponents of OSGi that are pointing at Jigsaw as the > "simpler > > alternative" are seemilngly missing the obvious fact that Jigsaw is still > > largely unknown quantity in the modularization world. > > > > Nobody has any actual real world exposure to building real modular and > > extensible applications with it and there is no telling what kind of > > problems are people going to get themselves into when jigsaw hits the > > fan... > > > > > > reede, 24. juuni 2011 19:25.14 UTC+3 kirjutas JessHolle: > >> > >> But that still leaves open the question as to whether the right solution > >> is to provide more tooling for OSGi or something simpler and possibly > >> better integrated with the language, e.g. Jigsaw. > > > > -- > > -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To view this discussion on the web visit https://groups.google.com/d/msg/javaposse/-/pFRbInZPTysJ. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
