Electronic Design

Eclipse: Write Once, Run Everywhere Platform

A rich Java client from an IDE turns into an application platform.

Sun's initial shot at Java on the desktop didn't fare well. Nonetheless, some notable Java desktop applications, such as Sun's StarOffice, have seen success. Initial criticisms of Java applications being too slow are long gone. Even with better performance, Java applications on the desktop were often found embedded within Web pages.

Now a change is afoot from an unlikely source, the Java-based Eclipse integrated development environment (IDE). Originally designed as a universal tool platform, Eclipse is slowly becoming a more comprehensive application platform, not just an application-development platform.

Although Eclipse's capabilities have always been there, it has taken people like Todd Williams, vice president of Genuitec LLC (www.genuitec.com), to bring them out. This is because Eclipse has been delivered as an IDE with all the bells and whistles. Most of these go away when using Eclipse as a rich client platform.

Williams notes that getting Eclipse down to a workable base at this time is no easy task, but it only needs to be done once. It's a matter of stripping out unnecessary plug-ins normally employed by the IDE. The next release of Eclipse, version 3, will actually address this issue.

Part of the Eclipse 3.0 development plan, the Rich Client Platform, is specifically targeted at non-IDE applications. A number of item features will be incorporated, such as user-setting support. Other work areas for possible inclusion include dynamic plug-in support, a security model, and even product branding.

The Rich Client support is in addition to a vast number of projects and improvements for Eclipse 3.0. The Eclipse IDE is already multilingual, with support for Java, C, C++, and Cobol. A little searching will turn up even more. The current version of Eclipse is already being used for a range of tasks, although many are related to software development.

Eclipse is slowly moving outside its IDE roots. Genuitec's MyEclipse (www.myeclipseide.com) is a J2EE (Java 2 Enterprise Edition) development tool that builds on the Java development support in the Eclipse IDE. While still a Java application development tool, MyEclipse adds plug-ins that address application deployment and testing.

TimeSys (www.timesys.com) is another company that makes extensive use of Eclipse. The TimeStorm IDE, based on Eclipse, includes C, C++, and Java development tools. It adds plug-ins for configuring and debugging TimeSys Linux and Linux-based applications.

The Linux Verification Suite (LVS) is a set of Eclipse plug-ins that span the testing range, from the Linux kernel to application testing. It incorporates over 1100 tests from the Linux Testing Project (LTP), along with many TimeSys-developed tests. Developers can include their own tests in the suite. The LVS supports automated testing, management, and analysis of test results. While the suite can be used by developers familiar with the Eclipse IDE, it can also be employed by quality assurance where the IDE aspects of Eclipse won't be needed.

Applications devoid of most or all of the IDE plug-ins are used, but they're well-kept secrets at this point. Genuitec's Williams indicates that many of the company's consulting customers take advantage of a stripped-down version of the existing Eclipse platform to deliver Java-based applications on a variety of platforms. The approach provides a robust write-once, run (and test) everywhere solution that many other platform-based solutions can't match. This is key to Web-based applications that require more than just a thin client. A rich client also has the advantage of being able to run in a standalone mode. To most users, there's no Eclipse platform, just an application.

The Eclipse platform can be used for standalone applications, but it becomes very interesting for combining or enhancing applications. For example, using Eclipse for a network switch management tool is useful. However, it becomes part of a larger system if the tool can be used with other plug-ins, such as an SNMP (simple network management protocol) management console. Implementing a scripting system or integration plug-ins can further enhance such an amalgamation.

Don't overlook the use of Eclipse within an embedded device. There are obvious minimal requirements as with most platforms, including Microsoft's .Net. Yet many devices possess the horsepower and storage, such as a hard disk, that make the Eclipse platform an option to consider.

With Eclipse's plug-in architecture, plug-ins can expose interfaces and require others. Therefore, it's possible to build extensible applications utilizing the underlying architecture. Other Eclipse features, such as remote updates, can be employed in keeping an application up to date.

Eclipse plug-ins can handle plug-in dependencies, but it's also possible to incorporate different collections of plug-ins, called features, within the same system. Different features can be accessible at the same time even though they may or may not interact with each other.

The Rich Client Platform for Eclipse 3.0 is expected by June 2004. This will formalize the use of Eclipse as an application platform. It's designed to provide minimal support with no IDE-specific features so that non-IDE applications can be compact.

This isn't to say that useful plug-ins can't be incorporated. In fact, it's possible to build up an IDE-like environment for an application using the Rich Client Platform as the base. It's simply a matter of the starting point, the desired result, and how much of the underlying system will be made available to the user.

The Eclipse platform offers a number of useful features as an application delivery platform. It employs the Standard Widget Toolkit (SWT) for graphical presentation versus the Swing graphic support often used with Java-based applications. Swing is great at providing a consistent look and feel across platforms. SWT provides a similar feel but the look is more in line with the native graphics interface.

For example, dialog boxes in Eclipse running on Windows look like a Windows application. Running on a Mac, the dialog boxes look like a Mac application. SWT also has an edge on performance due to its use of the underlying graphics system. This can put a chink in an application's portability between platforms if an application imports features that aren't found on all of its intended platforms.

Applications can use plug-ins from sources other than the various IDE-related development projects—of which there are many. For instance, Qanyon's Xtellify for Eclipse (www.qanyon.com) plug-in converts data from a variety of files to XML. This includes Microsoft Excel files, HTML, and LDAP. It can be used to extract information from spreadsheets or a database and deliver the XML encoded data via SOAP (simple object access protocol) to a remote server or embedded device.

Building an application on the current Eclipse platform isn't as hard as it might seem. There are only four core plug-ins, and the initial startup plug-in is specified in the install.ini file that includes feature.default.id and feature.default.application specifications. The former controls product branding, splash screens, and plug-in customization. The latter is the plug-in that has initial control of the system. The default IDE application is org.eclipse.ui.workbench. This provides the Eclipse IDE workbench environment.

The workbench metaphor incorporates perspectives that are a collection of views or windows, and these are user-configurable. A typical set of perspectives includes an editing perspective and a debugging perspective.

Workbenches, perspective, views, and other Eclipse IDE features can be useful for a non-IDE application. For example, the workbench user interface could provide a way to manage multiple networked devices or subnets. Alternatively, a workbench could coordinate projects within an application.

Eclipse gains its portability because the plug-ins are written in Java. The only requirements on the deployment platform are Java and SWT support. In the future, Swing support may be substituted for SWT.

Most embedded developers use C, but learning Java can be easier than tackling C++. More likely, though, is choosing Java because of the Eclipse platform's portability. Significant improvements in Java performance make it more than suitable for a user interface. This is especially true for microprocessors with Java acceleration. Likewise, many systems have 32-bit microprocessors with plenty of horsepower for snappy Java applications.

Eclipse obviously needs more work to be a robust application delivery platform. The Rich Client Platform goes a long way to reaching that goal. Areas not currently addressed or handled well, such as dynamic plug-in installation and deactivation, authentication and encrypted updates, and product branding, may be part of the 3.0 release or follow soon thereafter.

A host of other Eclipse projects offers support useful for some applications. For example, UML (Unified Modeling Language) integration will be significantly enhanced from a number of sources next year. UML could be used to present information or allow users to configure the application.

Still, Eclipse plug-ins for some areas may be few in number or non-existent. Grand-Rapids Developers (www.meyou.com/grandrapid/) offers a Web browser plug-in, but alternatives aren't numerous. The Rich Client Platform will change this view as Eclipse becomes known for more than its IDE roots. In the near term, count on writing support plug-ins for non-IDE support.

Tool and RTOS developers have warmed to the opportunity offered by Eclipse. The next step for Eclipse is clearly as an application platform. Given its Java roots, it's an ideal interface for embedded systems in native or remote applications.


See associated figure

Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.