With Eclipse, tools find common IDE

All too often, integrated development environments (IDEs) confine their scope to the "develop, build, debug" cycle. Other development tasks, such as system design and analysis, must be performed with specialized tools that live outside the main IDE. This double standard, with some tools tightly integrated and others left out in the cold, leads to an unnecessary-and counterproductive-proliferation of development environments. Even within a single project, developers can end up using one IDE to bring up their embedded board, another to write drivers in C, yet another to code applications in Java and still another to perform system analysis.

Some vendors have tried to extend their IDEs beyond this three-stage cycle, but with mixed success. The problem comes down to cost. Third-party tool providers, particularly those that provide the tools required to achieve this increase in scope, have found it too expensive to port their products to every IDE available. To complicate matters, few IDEs offer the control over the user interface and user experience needed to achieve complete tool-to-tool integration. Together, these factors make it difficult or impossible to bring all development tasks under one roof.

Enter the Eclipse framework. Eclipse provides a common integration mechanism that lets developers write tools once, then deploy them in almost any type of development environment, be it an IDE provided by an RTOS vendor or an IDE tailored for enterprise applications. As a result, tool vendors don't have to waste resources supporting multiple IDEs. Instead, they can focus on adding value to their specific tools. Moreover, Eclipse allows tools from different vendors to interoperate in the same environment and, in many cases, extend one another's capabilities. Consequently, even conventional tools like debuggers and application profilers can provide insight into a much wider range of problems like complex distributed behavior.

This extensibility played a key role in QNX Software Systems' adoption of the Eclipse framework. As an RTOS vendor, QNX has developed a set of core tools, like compilers and debuggers, tailored for embedded development. Using Eclipse's extensible plug-in architecture, software engineers at QNX found it easy to adapt those tools to the framework, allowing them to work interoperably with third-party Eclipse tools like source code control systems.

Moreover, Eclipse allowed QNX to expand the development focus beyond the "code" and into the actual embedded target. Specifically, it afforded QNX engineers the flexibility to develop nontraditional development tools-remote file system navigators, system profilers and plug-ins for target control-that provide the types of target information and run-time analysis important to embedded developers. It also allowed previously isolated or unextensible tools to share data with one another, without need for manual intervention. This integration improved work flow, further allowing developers to focus on understanding target system behavior.

The Eclipse framework gains its flexibility from extension points. These are well-known interfaces, defined in XML, that serve as the coupling points for plug-ins. An extension point can range from a simple string used in a regular-expression filter to the specification of a Java class that is invoked when a specific selection is made. Any Eclipse plug-in can define extension points that other plug-ins can use and, conversely, fulfill extension points defined by other plug-ins. Other than the knowledge of the interface defined by the extension point, plug-ins have no hard-coded knowledge of how the services they offer through extension points will be used.

To understand how this architecture allows an IDE to become more "target focused," consider a plug-in that QNX developed for analyzing heap allocation and general memory usage-a key concern for most embedded developers. This plug-in hooks into an extension point that allows monitoring tools to be run when any process is launched from the Eclipse framework. If any sort of memory error occurs while processes are running on the target, the plug-in records the error, then searches through available debugging extension points to establish a remote-debugging session with the process that generated the error. The plug-in can do all this without having any specific knowledge of the process that was launched or knowing how to connect the debugger to the target.

The tool-to-tool interoperability provided by Eclipse's extension-point model provides many other opportunities to understand target behavior. For instance, consider QNX's "system profiler," an Eclipse-based plug-in that hooks into an instrumented kernel to monitor system-level activity. If the system profiler detects an event sequence typically associated with poor performance (for example, a process receives several messages within a short time), it could, using extension points defined by an application-level profiler, trigger an application profiler session. Conversely, the application profiler can act as the trigger.

For instance, if a thread exceeds its defined boundary condition for response time, the application profiler could, using an extension point defined by the system profiler, trigger a system-profiling session to provide a system-level view. The root cause of poor performance is quickly identified using the integrated power of two, traditionally standalone, tools.

For another example of how the Eclipse architecture can enable a more target-centered approach, consider what happens when multiple languages are used to develop an embedded system. A system may be designed using a higher-level language such as UML or SDL, both of which represent components as abstract entities. Once designed, however, each component may be implemented in a language best suited for the device on which it is deployed. For instance, an embedded microcontroller might use assembly language while a midlevel line card processor might use C or C++, and a more substantial host might use Java.

Few tool environments let you regard all three of these components as one entity; even fewer allow the entire system to be debugged and stepped through with a single tool. Instead, you must examine components individually, even though they all work and communicate as a complete system defined in a high-level language.

With Eclipse, on the other hand, you can bring together the high-level design, perhaps done in UML, and low-level development tools, such as an application debugger. If these complementary standalone tools were connected to one another using Eclipse extension points, the UML diagram could, for example, highlight which component you are interacting with as you stepped through the application in the debugger. In fact, since Eclipse is agnostic about development languages, a Java language debugger, a C/C++ debugger and an assembly debugger can all be active-and targeted at different processes or nodes-at the same time in the same framework.

See related chart

There are still other examples of how Eclipse, with its generalized plug-in architecture and extension-point API, can influence the types of tools developed, and how those tools interoperate with each other. For instance, hardware debuggers (ICE and JTAG, for instance) and application debuggers (C, C++, Java and the like) can share a common debugger user interface, but provide implementations specific to the configuration they are debugging through a well-defined debugger extension point. This tight integration via extension points makes it easy for developers to transition from one task (stepping through the start-up code for an embedded device) to another (debugging applications running on the embedded device).

By integrating these and other tools within the same development environment, an Eclipse-based IDE like QNX's can significantly change project work flow. No longer do developers have to perform the traditional "develop, build, debug" cycle in one world, then change focus to examine actual operations on the target. Rather, they can use just one environment to both develop code and tune the target system based on the immediate feedback provided to analysis tools. Such feedback offers greater insight into how software components will behave "in the real world," regardless of whether the target is a simple standalone device or a massive distributed system comprising many nodes.

Thomas Fletcher is manager of the Tools Development Group at QNX Software Systems (Ottawa).