Equinox Refcard Now Available - An Interview With Jeff McAffer

DZone today launched the Equinox Refcard, covering everything that you need to know to get started on writing OSGi bundles for Equinox, Eclipse's OSGi implementation. The Refcard is written by the project's founder and co-leader, Jeff McAffer. I asked Jeff some questions about Equinox to coincide with the release of the Refcard.

Jeff McAffer leads the Eclipse Equinox OSGi, RCP and Orbit teams and is CTO and co-founder of EclipseSource. He is one of the architects of the Eclipse Platform and a co-author of The Eclipse Rich Client Platform and the upcoming book Equinox and OSGi (Addison-Wesley). He co-leads the RT PMC and is a member of the Eclipse Project PMC, the Tools Project PMC and the Eclipse Foundation Board of Directors and the Eclipse Architecture Council. Jeff is currently interested all aspects of Eclipse components from developing and building bundles to deploying, installing and ultimately running them. Previous lives include being a Senior Technical Staff Member at IBM and work in distributed/parallel OO computing as well as expert systems, meta-level architectures and a PhD at the University of Tokyo.

Sugrue: What is the extent of your involvement with Equinox?

McAffer: I founded the project and am currently co-leader with Tom Watson of IBM.  I led the initial push for Eclipse to move to OSGi and led the team that did the implementation work.  I also participated heavily in the OSGi spec process to ensure the R4 release was suitable for use in Eclipse.  Today I continue to work on parts of Equinox (particularly the p2 provisioning platform) and spend time looking at higher-level issues around adoption, ease of use, programming models for highly modular systems, ...

Sugrue: How does Equinox compare with other OSGi implementations?

McAffer: Every implementation has its pros and cons. 

• Equinox is an industrial strength implementation of the latest spec releases and drafts.   It is the reference implementation for all R4.* releases as well as JSR291.
• It is used daily by millions of people around the world either via Eclipse, as the underpinnings for countless RCP applications (eg.., Lotus Notes and Sametime, ...) or via the web for people accessing WebSphere servers. 
• The underpinnings of Equinox are also highly modular and flexible and allow for extreme customization of implementation behaviour.
• Highly scalable supporting mainline usecases of 5000-10000 bundles
• Equinox tends to have a somewhat larger footprint than some of the other implementations.  The raw JAR size is somewhat misleading as that JAR is signed (adding >100k), includes the console (~50K), lots of debugging etc.  Even striped down it will be larger but not by that much.
• Overall Equinox is more tuned for desktop and server applications whereas some of the other implementations are more suited to the embedded space.
• Equinox has a number of extensions to the spec to allow for smoother integration of third party libraries and handling of nasty context classloader issues

Sugrue: Who should consider using Equinox? What are the typical use cases?

McAffer: Equinox is completely general purpose and is in use today in everything from embedded mobile mission critical applications to enterprise backoffice server farms.  Of course, it is the runtime under all Eclipse-based systems so anything that it running Eclipse is running Equinox.

Sugrue: What are the most innovative uses of Equinox that you have seen?

McAffer: Wow, that's a hard question.  I've seen Equinox in airline check-in kiosks, ski-lift turnstiles, Mars rover mission planning software, embedded/mobile military applications, high performance application servers and a whole range of desktop applications.  These all have interesting and intriguing aspects.  They also have common threads -- the need the flexibility that comes with the extreme modularity OSGi and Equinox bring to the table.

Sugrue: What is the number one tip you have for using Equinox?

McAffer: Don't fight it.  Most of the problems I see people having when adopting Equinox (really OSGi in general) is the failure to embrace the modularity mindset.  This could be anything from writing huge bundles to not letting the tools (e.g., Eclipse's Plug-in Development Environment or PDE) help them.  If you work with Equinox and PDE development and deployment is extremely smooth and efficient.

Sugrue: Your long awaiting book on Equinox and OSGi is nearing publication – how is it progressing?

McAffer: The book is progressing well.  We have the first content up on Safari Rough Cuts and previewed the code at Eclipse Summit Europe as part of the Equinox Hackathon (http://wiki.eclipse.org/Eclipse_Summit_Europe_2008_Equinox_Hackathon).  We initially targeted an end of year release of the book but in the end decided that here are so many refinements and cool features coming in the Galileo (June 2009) release that we would retarget a simultaneous release of the code and the book.  So the book will highlight new features available in Galileo but will also cover Ganymede content.

Sugrue: Did you enjoy writing the refcard?

McAffer: Condensing a huge amount of functionality and flexibility into just a few pages was a considerable challenge.  No matter how you look at it, some "critical" things will be left out. That is frustrating.  In the end I tried to walk a balance between giving context to enable people going forward and step-by-step, concrete information to enable them immediately.  Hopefully people find it useful.

Download the Equinox Refcard here to find out more about how to create your own OSGi bundles.