software technology
Editor: Christof Ebert
n
Ve c t o r C o n s u lt i n g S e r v i c e s
n
ch ristof.eber t @ vector.com
Composing Systems with Eclipse Rich Client Platform Plug-Ins Andreas Kornstädt and Eugen Reiswich Eclipse Rich Client Platform (RCP) is a platform for building and deploying rich client applications. It offers a much richer user experience than is possible via Web technologies. Although companies such as Adobe, JP Morgan, and Swiss Rail have used it for several years, RCP demands good understanding to be productive. Authors Andreas Kornstädt and Eugen Reiswich describe how to get started. Their hands-on experiences should help readers master the steep learning curve. I look forward to hearing from both readers and prospective column authors about this column and the technologies you want to know more about. —Christof Ebert
W
e try to hide it, but we software developers have become lazy. After decades of building the software world as we know it from scratch and after some relapses into the “not invented here” mentality, we now try to build on top of as much prefabricated functionality as possible to focus on what we ultimately strive to do: solve
real-world business problems. It’s hard to imagine starting a new project today without spending some time looking for helpful bits and pieces of software on sites like SourceForge. The Java world has seen a tremendous increase in the number and quality of prefabricated soft78
IEEE SOFT WARE
Published by the IEEE Computer Society
ware components—both commercial and freely available—but one thing hasn’t changed yet: the mode of composition. For individually deployable Java components, we’re always either implementing framework interfaces or using a library’s dedicated functionality.
The Basics
Enter the Eclipse Rich Client Platform (Eclipse RCP). Developed out of IBM’s Eclipse integrated development environment (IDE), RCP is a generic platform for building IDE, non-IDE, and even non-GUI applications for the client as well as the server side. Adobe, JP Morgan, NASA, Swiss Rail, and IBM all use RCP components to build version control products and spreadsheet software, to store and retrieve images from the Mars Rover mission, to manage topological railroad network data, and to write software such as Lotus Expeditor and Lotus Symphony. Outside industry, RCP is the basis for open source software such as the Vuze (formerly Azureus) BitTorrent Client and the geographic information system (GIS) uDig. Besides introducing a host of novelties, Eclipse’s main contribution is providing the 0 74 0 -74 5 9 / 10 / $ 2 6 . 0 0 © 2 0 10 I E E E
SOFTWARE TECHNOLOGY
component model Java never had. With plug-ins, Java components finally have an accepted industry standard for using and providing functionality at the same time. This offers a completely new way to build Java systems: combining RCP plug-ins and OSGi bundles (see the “OSGi: The Platform That Drives the Platform” sidebar) all the way from top to bottom. Because Eclipse RCP is built on top of OSGi, Java developers can now choose from three kinds of components: ■■ Java archive files (jars) are zip files containing compiled Java class and resource files as well as a manifest describing the jar’s contents. To access functionality in jars, they simply have to be included in the classpath so that the Java virtual machine (JVM) can statically load them at start-up. ■■ OSGi bundles are jar files containing a manifest with extra entries specifying the functionality the bundle provides and the functionality it requires. Bundles explicitly hide nonexported functionality. In addition to the JVM’s static loading, OSGi bundles can be dynamically loaded and unloaded at any time. ■■ Eclipse RCP plug-ins are OSGi bundles with an extra plugin.xml file that specifies where the component’s behavior can be modified by other components (extension points) and the other components it modifies (extensions). In addition to a plain OSGi runtime, the Eclipse RCP runtime keeps track of how the system is composed out of plug-ins and lazy loads components only when they’re required. So, if we want to add an editor (red frame in Figure 1) to an existing application, we have to do a few things: first, identify the extension point our editor is going to extend. In this case, this is obviously the standard extension point for editors. In the vast majority of cases, some other of Eclipse’s standard extension points such as for views, perspectives, actions, and menus will be the right one. If not, we can specify custom extension points in a plugin.xml file if required. Once we’ve identified the editor extension point, the second step is to create an
OSGi: The Platform That Drives the Platform The first versions of Eclipse had their own runtime to provide the basis for any plug-in mechanism before adopting OSGi with version 3.0. Having its roots in the facilities management domain, OSGi allows for dynamic installing, starting, stopping, updating, and uninstalling of bundles at runtime. In addition, bundles can provide OSGi services—plain Java classes that provide functionality beyond a bundle’s boundaries. Services can be used and provided either declaratively (similar to Spring) or programmatically. Other than Eclipse Rich Client Platform (RCP), OSGi defines a standard and isn’t an implementation. Although it’s sufficient for dealing with Eclipse’s own Equinox implementation while in the Eclipse world, it’s important to keep in mind which features are based on the standard and which ones go beyond it. Not paying heed to this spells trouble when switching to competing Apache Felix or Knopflerfish implementations. You can find a useful Webinar for getting started with OSGi at www.eclipse. org/equinox-portal/getstarted.php.
Figure 1. Example Eclipse Rich Client Platform (RCP) application. The admin tool already contains a customer lister. Technically, it’s composed of a workbench with a toolbar and view. Once the editor on the right is added via configuration, it also contributes a save action to the workbench’s toolbar.
appropriate extension. This consists of writing extension XML code (as shown in Figure 2, top part) and coding the editor itself in Java. Although you can start from scratch, of course, Eclipse’s code wizards provide good templates. The final step is specifying under which conditions the editor should be started and which content it should present. One way to do this is by creating another extension—for example, for the customer lister’s popup menu extensions (see Figure 2, bottom part). This popup menu extension can listen for customer selections within the customer lister and create an action that starts the editor and provides
it with the selected customer. Once these steps have been done, you can change, ship, and test the editor and the main tool independently.
Hints for Practitioners
Although the basic concepts are easy enough to grasp, starting to use Eclipse RCP means crawling up an extremely steep learning curve. Just implementing the previously described example can take hours or even days if you want to get the nuts and bolts right. This stems from the quite recent merge of Eclipse RCP and OSGi technology, from dealing with Eclipse’s own GUI frameworks SWT and November/December 2010 I E E E S O F T W A R E
79
SOFTWARE TECHNOLOGY Figure 2. Extension for predefined editor and popup menu extension points. If you don’t like to write XML and manifest files, the Eclipse plugin development environment provides special editors to handle error-prone XML writing. However, this editor glosses over the fact that separate files are involved, so knowing the mechanism and the structure of the individual files surely helps.
outside modification or to modify another component from the outside (plug-ins). This isn’t exactly made easier by the fact that both can be done at the same time and that the terms “bundle” and “plugin” are used interchangeably almost everywhere. What really helps is calling them what they are and always using the simplest type of component that will work for your purpose: bundles for anything that doesn’t require GUI plugging, and plug-ins for everything else.
Where the Business Things Are
SWT and JFace Going with Eclipse RCP plug-ins to compose applications automatically means going with Eclipse’s Standard Widget Toolkit (SWT). Originally developed by IBM to have the complexity of Java’s Swing widgets without the limitations of Java’s Abstract Windowing Toolkit (AWT) widgets, SWT makes use of a platform’s native UI libraries. This high level of platform integration makes for good performance and a fully integrated look and feel. The price for this, however, is twofold. First, it means learning a completely new API with principles varying markedly from those of AWT and Swing. Second, it involves dealing with memory management rearing its head in the Java world, as each SWT component requires manual disposal to avoid memory leaks. As SWT doesn’t reach the ease of handling of Swing when it comes to dealing with complex widgets such as tables, lists, and trees, JFace was added on top of SWT. JFace’s features for data binding (“viewers”) and decoupling of events and actions, along with its wizards and other complex dialogues, go beyond what’s available in Swing.
JFace (with editors, views, actions, workbench, and perspectives—see the “SWT and JFace” sidebar), from finding ways to adapt standard strategies that rely on static linking to the highly dynamic world of components, and finally from the staggering number of projects and configurations Eclipse RCP is available in. Focusing just 80
IEEE SOFT WARE
w w w. c o m p u t e r. o rg /s o f t w a re
on the RCP’s plug-in aspect, we’ve found a few things that will help you circumnavigate the most dangerous cliffs.
While it’s easy enough to follow the latest articles on Eclipse RCP, most of them won’t help you answer a fundamental question when developing your own application software—on what basis to decide what functionality should go into what component, what kinds of components to have in the first place, how big they should be, and how many of them to have. Recommendations tend to be based on rather technical grounds and, for example, suggest either having very small components (“easy to upgrade”) or rather large ones (“avoid plug-in hell”). Although all these considerations are worthwhile, these technicalities change far too often for making them the basis of your component design. Don’t get thrown off course by these debates and stick to the most stable elements of your application: business logic. Every application is different, so having separate bundles for each service implementation, each service proxy, and each domain as well as one plug-in for each tool cluster is surely a good starting point.
A Rose Is a Rose Is a Rose
A Plug-In Framework without Plug-Ins Ain’t a Plug-In Framework
It takes some time to get a feeling for when to use or provide functionality (bundles) and when to open a component for
We’ve seen it before with plain Java: developers entering from the procedural side write syntactically correct Java code, but if
SOFTWARE TECHNOLOGY
you look at it, it’s basically all static code around static void main(). To avoid déjà vu in Eclipse, don’t put your applications code in RCP’s equivalent to main , the so-called application plug-in. While tempting at first for some quick tryouts, be sure not to let your plug-in application become a monolith that’s hard to carve up later because it’s tied fast to that specific plug-in.
Putting Things into Perspective With RCP, the layout of views and editors including their position and size is arranged with perspectives. If the user makes changes to that arrangement, Eclipse stores the new positions so the application starts up exactly in the way you left it. To specify the initial layout, however, developers have to make some stark choices: either contaminate the program code or the plug-in.xml with layout information. As long as Eclipse provides no special layout files, we think a plugin.xml is a better place as it’s far easier to find a perspective within the plugin.xml than it is to search for classes containing layout descriptions.
Testing outside the Box Now you have code in your plug-ins, but where do you put the tests? Follow Java standard practice and put them in special source folder inside the plug-in? Or use a separate test plug-in? We say don’t do either: test folders inside the plug-in make it hard to strip plug-ins of their test code when it’s shipping time, and using separate test plug-ins entails limiting your tests to the published interfaces only. Although not a very well-known part of the specification, consider putting your test code into fragments, special plug-ins that have full access to precisely one host plug-in, so they’re outside (for shipping) and inside (for access) the plug-in under test at the same time.
“F
ocus, Grasshopper” never rang truer than in the context of the Eclipse RCP universe with its well over 100 projects. There are so many paths to explore that it’s almost unavoidable to get lost more than once. While many of those projects will die and even more will be born, we think that Eclipse’s plug-in model is a key step in the evolution of the Java platform, which is here to stay. When you’re into building
Resources Although there’s a wealth of Eclipse literature, the ultimate place to go is still www.eclipse.org/articles/Article-Plug-in-architecture/plugin_architecture.html. We could only barely scratch the surface of Eclipse RCP in this installment of Software Technologies, but our recent article “Staying Afloat in an Expanding Sea of Choices: Emerging Best Practices for Eclipse Rich Client Platform Development” in Proceedings of the 32nd ACM/IEEE International Conference on Software Engineering (ACM Press; http://portal.acm.org/citation. cfm?id=1810295.1810305) gives much broader, in-depth coverage of the subject, especially on how to group functionality into bundles and plug-ins. If you’re looking for pointers into the Eclipse world, the following links are good starting points: ■■ http://eclipse.org/community/rcp.php (showcase of commercial and open source RCP projects) ■■ www.eclipse.org/articles (articles written by the RCP development team and other members of the Eclipse community) ■■ http://help.eclipse.org/help33/index.jsp?topic=/org.eclipse.platform.doc.isv/ reference/misc/update_standalone.html (Eclipse developers guide with many screenshots) ■■ http://rcpquickstart.com/2007/06/20/unit-testing-plug-ins-with-fragments (testing RCP applications with fragments) ■■ www.eclipsezone.com/articles/extensions-vs-services (Neil Bartlett compares extension points and extensions with OSGi services)
a system that consists of more than a few classes, you should consider setting aside some time to evaluate it. Even if the decision will be to not use RCP, it’ll surely give you valuable inspiration for building your own modularized systems.
Andreas Kornstädt is a freelance software architect,
consultant, and researcher at Hamburg and Stanford’s Center for Computer Assisted Research in the Humanities (CCARH). His research interests include computing in musicology, component-based architectures, and agile development processes. Kornstädt has a PhD in computer science from Hamburg University. Contact him at
[email protected]. Eugen Reiswich is a project lead at C1 Workplace So-
Selected CS articles and columns are also available for free at http://ComputingNow.computer.org.
lutions (C1 WPS). His research interests include control system development and component-based architecture. Reiswich has a diploma in information systems from Hamburg University. Contact him at
[email protected].
ADVERTISER INFORMATION NOVEMBER/DECEMBER 2010 ADVERTISERS ICSQ 2011 5 Industrial Technology Institute 8 John Wiley Press Cover 2 Seapine Software Cover 4 ADVERTISING PERSONNEL Sr. Advertising Coordinator: Marian Anderson Email:
[email protected] Phone: +1 714 821 8380; Fax: +1 714 821 4010 Sr. Business Development Mgr.: Sandy Brown Email:
[email protected] Phone: +1 714 821 8380; Fax: +1 714 821 4010
ADVERTISING SALES REPRESENTATIVES Western US/Pacific/Far East: Eric Kincaid Email:
[email protected] Phone: +1 214 673 3742 Fax: +1 888 886 8599 Eastern US/Europe/Middle East: Ann & David Schissler Email:
[email protected],
[email protected] Phone: +1 508 394 4026 Fax: +1 508 394 4926
IEEE Computer Society 10662 Los Vaqueros Circle Los Alamitos, CA 90720 USA
November/December 2010 I E E E S O F T W A R E
81
