Eclipse Virgo

“The driving reason behind this decision,” [Adam FitzGerald, director of developer relations at SpringSource] said, “is that, although OSGi is a very successful technology, it still hasn’t reached mainstream penetration for the average enterprise Java application. And we think that has been a hindrance to the productivity of enterprise Java in general, and to the success of our customers and user base.” –from John Water’s coverage of Virgo

VMWare/SpringSource announced that it was donating its dm Server product to the Eclipse Foundation yesterday. See the Eclipse Foundation proposal here for the details of the new project, Virgo. The dm Server is one of SpringSource’s post-appserver appservers, along with tc Server which wraps up Tomcat to be used as a stand-alone runtime. dm Server is more oriented around providing a runtime and the supporting tooling for OSGi-based applications, which I tend to view as the next phase of Java development. Us RedMonks like to call this the “stackless stack.”

Accelerating OSGi Adoption

OSGi has seen wide adoption in the vendor community where the likes of IBM, Oracle, SAP, and even Sun have shown interest and/or are using OSGi as the foundation for their own application servers and runtimes. When speaking with SpringSource’s Adrian Colyer about Virgo last week, he didn’t indicate that dm Server had seen massive customer up-take. Indeed, as FitzGerald’s quote at the top gets to, part of sending dm Server over to Eclipse is to try and sprinkle gas on that slow burning fire. And I agree that this is a good strategy.

Wide-spread adoption of OSGi has been a long process, but it’s far from unsuccessful at the moment. In fact, I’d say the OSGi community – largely helped by folks like SpringSource and Eclipse – is finally well positioned for main stream adoption by those looking for a new way to handle the fundamental building blocks of their Java applications.

Interested Parties

So far, there are several parties officially interested: SpringSource, TaskTop, SAP, and, of course, Eclipse.

• SpringSource’s interest should be clear: seeding the Java market with the type of Java they would like to see, narrowing down the portfolio for VMWare integration by sharing project stewardship with the wider community, and moving the Spring Framework (which dm Server is oriented around) closer to Java middleware commoditization. From a SpringSource and VMWare perspective – and those of individual contributors – all of this is good.
• TaskTop had been the third party developing the tooling around dm Server, and with their deep entangling with the Eclipse ecosystem, having dm Server and the wider OSGi adoption increase helps them. Similar to folks like Genuitec and SmartBear, TaskTop has done the unthinkable in today’s development world: building a good looking business out of selling developer tools. While TaskTop isn’t tied to Java, the success of post-JEE companies like SpringSource helps grow the pie, as they say, for TaskTop.
• SAP, like all companies that use J(2)EE – Netweaver for SAP – knows how much the Java world needs modular Java and, no doubt, looks at OSGi as one of the best hopes. Light-weight Java runtimes like Jetty (also at Eclipse now), Glassfish, and SpringSource’s offerings have reinvigorated interest in the lumbering world of application servers. Any vendor offering such lumbering is looking to limber up, if only for themselves – a feeling that must be acutely felt at SAP and Oracle who have to (or should be) eat their own dog food to deliver their enterprise applications as well.
• Eclipse for sometime has been pursing and honing EclipseRT, building out its reach from IDEs and GUIs into the server side. Once dm server moves out of proposal mode, EclipseRT will have a broad range of server-side runtimes to pick from: SOA with Swordfish, bare-bones/DIY with Equinox, Tomcat style web container with Jetty…and much more to offer when it comes to the foundation for building applications. This is beneficial not only for organizations lookingto build Java applications, but for vendors who’d like to commoditize these fundamental runtimes and build value (read: charge money) on-top of them.

Action Plan: Java developers, architects, etc.

For the “slow burn” comments above, the big question is if you should care in the first place. I’d say yes, esp. for green-field projects. The modular Java encouraged by OSGi should provide a better way to break-up your applications. It may not be perfect, but the wider community is starting to think so. I can’t quantify it at all, but the outlook looks good for OSGi tools, compatibility, and future working knowledge. There’ll always be other options – esp. the modular thinking being bundled into standard Java. Waiting until the perfect solution becomes part of standard Java is always an option if you’re more conservative: we lived for a long time without attributes and generics.

If you’re not familiar with OSGi already, getting familiar with how it would apply to existing and new Java projects is probably a good idea. You’ll at least need the knowledge to evaluate claims made by the likes of SpringSource that OSGi-based Java is the way to go, like, if you want to use those magic clouds they’re hopefully cooking up with their VMWare parents.

There’s no end of help on the web, and Craig Walls’ recently released Modular Java seems like an accessible intro and overview. All of the interested parties above, and others, will try to steer you towards their sue of OSGi, so it’s important to keep in mind the OSGi standard vs. proprietary features as you look around (even if that’s in open source projects).

(Yeah, I know that’s Vigo up there, but that’s all I can think about when I read “Virgo.”)

More

• John Water’s piece for ADT
• SpringSource’s Adrian Colyer’s post.

Disclosure: Eclipse is a client, and SpringSource has been a client in the past. SAP is a client, has has been Sun and several others (see the RedMonk client list) who’re interested in this space, pro-OSGi or not.