DOWN TO THE BARE BONES
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.
IT'S STILL JAVA
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.
WORK IN PROGRESS
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.
Eclipse.org
www.eclipse.org
See associated figure
DOWN TO THE BARE BONES
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.
IT'S STILL JAVA
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.
WORK IN PROGRESS
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.
Eclipse.org
www.eclipse.org
See associated figure