Mule says no thanks to OSGi.

Ross Mason of MuleSoft posted an article where he argues that OSGi is too complex for end user developer. Although I can sympathize, I do not completely agree. Yes there are areas where OSGi is middleware centric. Yes there are always things that should be simplified. Yes there are pains moving to OSGi.

OSGi is a Dynamic Module System for Java. The key word is Module. Modularity is hard, not OSGi. Properly drawing boundaries between components is hard. Getting communication protocols and APIs right is hard. Unlearning habits of the past is hard.

Dynamic is not something that a regular developer ever learned to deal with properly. For years we have been in a servlet world, where one never really worried about resources/services disappearing or even cared about writing code to account for a multi-threading. I still see code that treats HttpSession as a private HashMap.

Think about all the iterations that enterprise Java went through and all of the technologies involved. CORBA, EJB1, EJB2, RMI, JINI, JNDI, JSP, JDBC, JMS, JCA, JPA, WS-(death)*, and on and on. How many books, articles, man-years of effort and learning went into getting developers to understand that set of technologies? All sorts of stacks and frameworks were built to hide the complexities of that set of technologies. Struts, WebWork, iBatis, Hibernate, Spring (later validated with EJB3/JEE5 and 6), Facelets, Seam, etc. That is a lot of effort from a lot of very smart people to get us to where we are now. It is very easy now to write an app in 3-4 weeks that is useful, pretty and functional. The same would be one to two years of manpower with EJB+JSP+"name the container you hate the most" just seven, six or even five years ago.

With OSGi the situation is very similar to the days of EJB1. Very little information was available in dead-tree format (until recently) and not too many people who you knew were using OSGi. Advice was hard to come by. Surrounding ecosystem was narrowly focused on middleware, embedded devices or Eclipse plugins. The situations is improving dramatically lately. Books are getting published (check out OSGi in Action and Spring DM in Action). OSGi Alliance has started a wiki to spread the jungle knowledge. Many OSS projects are picking up OSGi and provide feedback and information on project specific pages.

OSGi is a great technology, but it is fairly low level technology. It is like coding your whole application persistence logic with JDBC all over again. There are number of OSGi specs that address most of perceived complexities of OSGi: Declarative Services (DS) and Blueprint (Eclipse/SpringDM and Apache Aries) bring DI capabilities to OSGi. Building OSGi bundle metadata becomes simpler by the use of tooling support provided by bnd, bundlor and IDE tooling. Containers like Apache Karaf and Eclipse Virgo are simplifying the use of OSGi with each release.

Having said that, there is one issue with OSGi. Please bear with me while I address it in a roundabout way.

I think it was 2007 or 2008. I was at the SpringExperience/SpringOne conference. There was a lot of talk about data grids, super-duper distributed caching, mass scaling. All that sounded like candy to me. During one of the BOFs I asked Rob Harrop of SpringSource fame - "what is stopping adoption of this technology for use in an everyday project". His answer was very interesting and I wish I wrote it down, but it boiled down to (paraphrasing) :

Developers want to use APIs and tools that they already know. If there are serious limitations on usage of those tools and APIs, developers tend to scream bloody murder and bail.

OSGi is a different programming model from what we have learned to use so far. It has different quirks (TCCL handling is undefined in the spec for example) and not all libraries that we grew up with play nicely in that different programming model. Until all/most of the current cream of the crop libraries work seamlessly, or with very limited, configuration-only changes (no recompile/re-bundling required), there will be a push back on OSGi adoption.

I do not consider myself an OSGi evangelist or a zealot. I really do not think that OSGi is a golden hammer or a nail. OSGi and modularity forces architects and developers to think about overall architecture in much more detail. There are projects that just don't need it. But there are applications that will benefit greatly from OSGi support. Those applications will tend to have a longer lifespans without complete rewrites and will be less complex after 2 years in production than a usual package tangle that is found in other so called "enterprise" applications.

dmServer plans and osgi services

SpringSource dmServer is very nice piece of equipment. One of the major additions to the OSGi arsenal is concept of plans. Plans are deployment descriptors that allow for composition of application assemblies and provided added capabilities like scoping. You can think of scoped plan as a pseudo bundle that shades all included artifacts and creates a concept of a nested classloader. Very similar to jee concept of nesting wars and ejb-jars in ear. This is very useful addition that allows normal use of ORM libraries like hibernate that use TCCL (thread context class loader) and expect all classes to be found by classpath scanning. Scoping also hides services published within a scoped plan. No service gets out from a scope into a global service registry.
This is all nice and dandy, but what if you do want to "jail break" a service from a plan? Well there is a very simple way to do it. As Glyn describes in this thread on SpringSource dmServer forums, it's as simple as adding a service property.

Example:

<service id="publishIntoGlobal" interface="java.lang.CharSequence">
<service-properties>
    <beans:entry key="com.springsource.service.scope" value="global" />
</service-properties>
<beans:bean class="java.lang.String">
 <beans:constructor-arg value="foo"/>
</beans:bean>
</service>

Is JSR294 Active or Inactive?

I was surprised to find out that JSR 294 was marked inactive (here). Is it really inactive? It depends on who you ask. From Alex Buckley email for JSR 294 mail list, 294 is still alive:

The PMO has a new rule: a JSR that doesn't produce an EDR for 18 months is marked inactive. Nothing else happens, just the marker.

Officially, 294's last EDR was December 2007. However, as per the agreement with 277 and 294 EG members in December 2008, 294 was revived ain January 2009.

Materials for an EDR were presented privately to the 294 EG in June 2009. You and BJ sent useful comments. Just about the time I was ready to file the EDR, the Simple Module System proposal showed up. I can only imagine the complaints had I proceeded with the EDR at that time.

So, I will file an EDR this month based on the materials from June, along the following lines:

- Module accessibility is a JLS concept; runtime module is a JVMS concept.

- Module compilation unit is a JLS concept; it defines a module name + version; it is annotatable; its contents are implementation-defined.

- java.* APIs are limited to representing runtime modules and (the runtime form of) module compilation units.

Direct link here