Just to complete
our "wish list" we might as well throw in that it's used and supported
by several industry leaders that are powering commercial offerings with
the technology, created and maintained in an open-source community,
royalty-free and licensed to provide worldwide re-distribution rights.
Although these requirements may sound like a pipe dream, if you're a
Java application developer you may already have this incredible application
framework installed on your machine. It's the Eclipse Platform.
But Isn't Eclipse
a Java IDE?
The short answer
is yes and no. The FAQ
of the Eclipse Project (located on the web at http://www.eclipse.org
) contains the following definition: "The Eclipse Project is an open
source software development project dedicated to providing a robust,
full-featured, commercial-quality, industry platform for the development
of highly integrated tools." So by definition, Eclipse is an open platform
for tool integration, not an IDE. The issue has been confused because
a complete industrial strength, full function Java IDE is provided with
the Eclipse Platform, in the form of plug-in components that extend
Eclipse's basic framework facilities.
the framework for combining disparate tools into a single integrated
application with a seamless user interface. New tools are integrated
into the Eclipse Platform and its user interface through plug-ins that
extend Eclipse's facilities and provide new functionality. Additionally,
Eclipse plug-ins can extend other plug-ins. When an Eclipse based application
initializes, it discovers and activates all of the plug-ins that have
been configured for the workstation. The Eclipse platform is quite literally
the sum of its parts since it is capable of performing any function
that has been added to it by the plug-ins it currently contains.
Since being able
to write and test such plug-ins is essential to the success of Eclipse,
the Eclipse platform is bundled with a plug-in development environment
(PDE) and a set of Java development tools (JDT) to support it. The Eclipse
developers clearly trusted the power of the frameworks they created.
The entire development environment is just another set of tools integrated
into the platform using the standard plug-in techniques. The Eclipse
Platform itself was itself created by developers using the Eclipse based
Java IDE (initially in beta form). Since it's open-source, you can inspect
the code and understand in great detail exactly how the frameworks are
It is this practice
of packaging the development tools with the platform that causes some
to be confused about the nature of Eclipse. The JDT components are so
effective that they?re attractive to all Java developers, not just those
writing plug-ins. On the surface, Eclipse appears to be just an excellent
Java IDE. But instead of thinking about Eclipse simply as a Java IDE,
try to think about it as a desktop application that happens to include
a Java IDE, which was built using the underlying Eclipse platform as
an application framework.
Eclipse Framework Features
As an "IDE for anything,
and nothing in particular," Eclipse embodies an extensible design that
maximizes its flexibility as an IDE platform. However, the Eclipse architecture
defines sets of layered subsystems that allow it to be used as a framework
for a portable desktop application (or suite) that is not an IDE. The
following sections describe the primary Eclipse features that make it
attractive as a general application framework.
over time so developers often expend considerable effort designing applications
so that they are flexible and extensible. Eclipse is built around a
highly flexible and extensible plug-in model to enable any type of tool
to be added to the platform. If you begin to think of a desktop application
as a tool, or set of tools, it immediately becomes apparent that your
application functions and facilities can be added into an Eclipse based
desktop as a set of plug-ins, just as Eclipse's native Java IDE capabilities
a content model built around the concept of a workspace into which tools
(applications) can be installed. The tools operate on resources that
are organized into projects within the workspace. Projects contain a
tree structure of resources, which are folders and files containing
any type of content. The core platform provides a large number of extension
points that allow customization of all aspects of resource life-cycle
categorized nature of the content model lends itself to many types of
desktop applications with a bit of thought. For example, a simple email
client could be built upon a workspace that contains a single project
associated with the user's email account. The user's project could contain
folders for the common functional email elements such as inbox, outbox,
and sent items. Each of these folders could contain the corresponding
set of email messages as project resources.
The Eclipse platform
contains a standard widget toolkit, SWT, which is implemented natively
on all supported Eclipse platforms. SWT contains a large set of events,
layout managers, and widgets. When a supported platform does not contain
a native widget that is supported by Eclipse, such as a toolbar on Motif,
an emulated widget for that platform is provided. SWT also interacts
with native desktop features, such as drag and drop. Additionally, SWT
can use OS-specific components, such as Windows Active/X controls, if
such functionality is more desirable than full platform portability.
So far, SWT has been proven on the Windows Win32 and PocketPC, Photon,
Motif and GNU window managers, covering deployment platforms from high-end
workstations to embedded devices.
Although the Java
language already contains two widget toolkits, AWT and Swing, the Eclipse
group still chose to implement their own. The detailed reasons for this
choice can be found in the Eclipse Overview white paper.
However, to prove to yourself that this was the right decision I suggest
that you compare the look and feel of a Swing or AWT application of
your choice to that of Eclipse. Eclipse looks, feels, and responds like
a native application on whatever platform it is running on. Naturally,
this is also how you'd like your application to perform.
To build a graphical
interface, SWT may either be used directly or through JFace, the user
interface framework of the Eclipse platform. JFace includes dialog,
preference, progress reporting, and wizard frameworks as well as image
and font registries that make user interface creation very straightforward.
The Eclipse platform
supports a multi-window, MDI-like user interface presentation. On top
of JFace and SWT the Eclipse workbench provides a framework for building
perspectives, editors, and views that provide the structure for user
interaction. Editors handle resource life-cycle interactions such as
creation, editing, saving, and deleting. Views are used to provide supplementary
information about an object with which the user is interacting. Examples
include outline, pending tasks and property views. A perspective is
a stacked, tiled, or detached arrangement of views and editors. Only
one perspective is visible within a window at a time but you may open
multiple windows to view multiple perspectives simultaneously.
The Eclipse user
interface framework is extensive, flexible, and powerful. And, even
if it doesn't do everything you need, it can easily be extended for
much less investment in time and resources than designing and building
of the biggest problems associated with desktop applications is the
support cost incurred to package, distribute, maintain and upgrade the
application as new versions are released. This cost increases when a
large and dispersed user community uses the application. With an offering's
success and broad deployment, support after the sale can become time
consuming and expensive.
and upgrade facilities were part of the design of Eclipse from the beginning.
To control ongoing cost and remove maintenance issues that could become
barriers to project development and deployment, the Eclipse platform
contains a flexible update manager. The update manager can be configured
to perform both initial installations of new components or updates to
existing components from a remote server. As you release new versions
of your application or add-on components, distribution can be as easy
as packaging them using Eclipse facilities and placing them on your
desktop application has a help system for end users, and Eclipse is
no different. However, Eclipse's help system isn't simply built from
a static group of HTML files that tell you about Eclipse. Rather, it
is a framework for providing both searchable and context-sensitive help
that is open for extension by documentation plug-ins. Once your application
is complete, everything is available for constructing, packaging and
shipping a complete; custom, context-sensitive help system without purchasing
as an Application Framework
So starting with
the underpinnings of your favorite IDE as an application framework may
at least sound possible, but why would you do it? Eclipse satisfies
the full function and facility wish list mentioned earlier, while providing
the program development environment for building the project as a series
of Eclipse style plug-ins. You'll have an application that is architecturally
sound, extendible for future enhancements, interoperable with other
plug-ins (even those created by others), and can upgrade itself remotely.
The main question then becomes how much of Eclipse do you need?
Simply stated, an
application can be built upon the Eclipse framework by removing functions
that you don't want and then adding functions that you do. Removing
Eclipse functions is the easy part; just take out plug-ins that provide
unneeded features. If you're not building another IDE, a good place
to start is to remove all the JDT, PDE, and VCM (version control management)
plug-ins. With that starting point, and a bit of experience you can
evaluate components and continue to remove unnecessary features by removing
the corresponding plug-ins.
Once you pare down
the plug-ins to the bare minimum, you'll find that Eclipse still has
a few development capabilities represented in the UI. To remove these
from the framework, slightly more invasive techniques will have to be
used. The workbench UI plug-in provides the base UI capabilities of
Eclipse. Removing extensions from the plug-in's XML descriptor is an
easy way to further reduce visibility to the extra features that your
application doesn't require.
After all unnecessary
plug-ins are removed and you've minimized the extensions in the workbench
UI, there is still one more avenue available to further reduce the base
framework size. Since Eclipse really was intended to be a framework
for integrating development tools, a few of Eclipse's low-level development
concepts are built into the workbench UI plug-in directly rather than
being provided as extensions. The easiest way to remove them is to simply
comment out the undesirable features in the source code and rebuild
the plug-in. While this is unfortunate, keep in mind that "unwriting"
a few bits of code is still much easier and faster than writing an entire
application framework. Clearly, if you take this approach, you'll need
to be able to repeat the changes when migrating to new versions of Eclipse
source code, at least for a little while.
But now for the
good news: recently, the Eclipse team has recognized that such new and
innovative uses of Eclipse should be supported at the platform level.
Version 3.0 of Eclipse, which is currently in development, has a stated
goal that specifically targets enabling the use of Eclipse as a rich
client platform. If you'd like to track the progress of this enhancement,
you can find that it has been accepted as part of the 3.0 plan, which
is available on the Eclipse website, and is tracked as enhancement number
36967 in their bug reporting system.
Even if you need
to make other changes to Eclipse, the Common Public License that controls
access and use of the Eclipse Platform permits you to make and distribute
commercial derivative works from its source. There is no license requirement
to remain compatible with Eclipse, or donate changes back to the open-source
project, but it's clearly to your advantage to stay as standard as possible.
Isn't open source
great? Although intrusive, at least currently, the process is actually
quite straightforward. With a working knowledge of Eclipse's architecture
and a couple of hours an "empty" Eclipse application that looks like
the following can be created.
Once the unnecessary
functions have been removed from the framework, building your application
is simply a matter of writing your own plug-ins, adding features to
the basic Eclipse framework and branding them with your own logos. For
a large application, consider writing it as multiple custom perspectives
and supporting views. If you have a suite of small applications, perhaps
each one can be a single perspective. Or, maybe you'll use Eclipse as
a portal to integrate all your company's homegrown applications. The
possibilities are endless.
As we mentioned
earlier, to completely remove all the IDE-centric features from Eclipse,
source code modifications are eventually required until version 3.0
is available. This is unfortunate, but not unexpected. Remember, the
designers of Eclipse set out to build an "IDE for anything, and nothing
in particular", not a "general purpose application framework for anything,
and nothing in particular." However, as with many software projects,
the rule of "unintended consequences" kicked-in as developers realized
that the capabilities making Eclipse a great IDE can also make any desktop
application truly first-class. And the Eclipse team has listened well
and will deliver what we all need for rich client development in version
Appendix A - SWT Overview
One of the most
talked about components of Eclipse has been the Standard Widget Toolkit,
or "SWT." This component is designed to provide portable user interface
facilities that directly call the window manager of the underlying operating
system. This differs considerably from the approach taken by Swing technology,
which emulates user interfaces bit by bit and then presents the entire
interface bitmap to the underlying window manager for display to the
user. Speed and responsiveness result from the improved efficiency of
letting the operating system's window manager do the work. Users already
familiar with the appearance of widgets created by their operating system's
native window manager are happier not having to accommodate a new look
and feel. In face, SWT will allow you to build applications that are
indistinguishable from other platform applications.
SWT itself was focused
on delivering efficiency and speed. It's a thin layer that conforms
the API calls for standard widgets like lists, buttons and text boxes
into a transportable interface. There is no separate peer layer as in
the AWT class library. The SWT widget directly calls the underlying
operating system's window manager. Platform integration is not just
a matter of look and feel. Tight integration includes the ability to
interact with native desktop features such as cut and paste or drag
and drop, integrate with other desktop applications.
a functionally rich "least common denominator" of user interface
widgets in three ways. Features that are not available on all platforms
can be emulated on platforms that provide no native support. For example,
the Motif widget toolkit does not contain a tree widget. SWT provides
an emulated tree widget on Motif that is API compatible with the Windows
native implementation. Features that are not
available on all platforms but not widely used have been omitted from
SWT. For example, the Windows calendar widget is not provided in SWT.
Extended window manager features that are specific to a platform, such
as Windows ActiveX are accommodated through separate well-identified
packages. The design point for SWT provided all of the widgets
that were necessary for integrating typical development tools.
SWT has to remain
simple in order to run successfully on a variety of operating systems.
Sometimes the underlying behavior of the window manager impacts the
way that applications paint, and SWT generally lets the operating system "win." Functional portability is established by ensuring that all but
the lowest level direct interface calls to the operating system are
written in Java. This has proven itself as SWT has been ported again
and again to new environments. The calls across the Java Native Interface
to the operating system's C/C++ APIs are straightforward, making it
easier to accommodate new platforms. Most users like fact that the resulting
interfaces look just like others rendered by their workstations.
To bring some consistency
to user interfaces implemented for the Eclipse Workbench, SWT includes
support for creating custom widgets, leading to specific application
look and feel. This consists of a small set of carefully designed components
that have proven generally useful. This includes extended support sensing
user selected default color selections and border widths using mechanisms
provided by the operating system window manager.
The complete programmer's
guide for working with SWT GUI components can be found in the Eclipse
Project documentation found at:
Since SWT is royalty-free
open-source (licensed under the Common Public License) you can also
review the actual source code, also available from the eclipse.org website.
There are separate versions for each supported operating system / window
manager combination - now including more than eight popular platforms.
If, after evaluation,
you decide that you don-t want to use Eclipse as an application framework,
but want to use the SWT widget set as a replacement for Swing or AWT
you can easily do that too. Just add the SWT jar file to your application's
classpath and place the SWT shared library on your library path and
build your SWT user interface. You've now got a completely new UI that
will make your application look like a native on whatever platform it
is running on. Be forewarned that the programming model for SWT is different
than Swing or AWT, but once you begin to use SWT you'll soon realize
that the differences are actually a benefit.
of Using SWT
following information overview summarizes the content of the SWT sections
of the Eclipse Programmer's Guide.
applications start by creating a "Display" representing a SWT session.
A "Shell" is created to serve as the main window for the application.
Functional and display widgets are created within the shell. Characteristics
and states of the widgets are initialized and event listeners are registered.
When the shell window is opened, the application consumes the event
dispatch loop until an exist condition is detected, typically when the
main shell window is closed by the user. At that point, the display
must be disposed of.
The "Display" represents the connection between SWT and the underlying platform's
GUI system. Displays are primarily used to manage the platform event
loop and control communication between the UI thread and other threads.
For most applications, you can follow the pattern used above. You must
create a display before creating any windows, and you must dispose of
the display when your shell is closed.
A "Shell" is a "window" managed by the OS platform
window manager. Top-level shells are those that are created as a child
of the display. These windows are the windows that users move, resize,
minimize, and maximize while using the application. Secondary shells
are those that are created as a child of another shell. These windows
are typically used as dialog windows or other transient windows that
only exist in the context of another window.
When your application
creates a widget, SWT immediately creates the underlying platform widget.
This eliminates the need for code that operates differently depending
on whether the underlying OS widget exists. It also allows a majority
of the widget's data to be kept in the platform layer rather than replicated
in the toolkit. This means that the toolkit's concept of a widget lifecycle
must conform to the rules of the underlying GUI system.
Some widget properties are set by the operating system at
the time a widget is created and cannot be changed. For example, a list
may be single or multi-selection, and may or may not have scroll bars.
These properties, called styles, must be set in the constructor.
In some cases, a particular style is considered a hint, gracefully ignored
on platforms that do not support it. The style constants are located
in the SWT class as public static fields. A list of applicable constants
for each widget class is contained in the API Reference for SWT.
SWT explicitly allocates and must explicitly free operating
system resources. In SWT, the dispose() method is used to free
resources associated with a particular toolkit object. If you create
the object, you must dispose of it. When the user closes a Shell, the
Shell and all of its child widgets must be recursively disposed. It's
possible in SWT to register a disposal listener for each widget that
can automatically free associated graphic objects. There is one exception
to these rules. Simple data objects like Rectangle and Point do not
use operating system resources. They do not have a dispose() method
and you do not have to free them.
Control is a widget that typically has a counterpart representation
(denoted by an OS window handle) in the underlying platform. The org.eclipse.swt.widgets
package defines the core set of
widgets in SWT. The current list of all SWT controls can be found in
This article has
demonstrated that Eclipse can be "both a floor wax and a dessert topping."
It is a complete universal tool integration platform, a platform for
building IDE's for any language, a Java IDE, a better Java UI widget
set, and a portable, a la carte application framework. Serving a broad
array of project development needs, Eclipse has delivered something
there for everyone.
B - SWT Controls
A Control is a widget that typically
has a counterpart representation (denoted by an OS window handle) in
the underlying platform. The org.eclipse.swt.widgets package defines the core set of widgets in SWT. They include the
following control types:
- Button - Selectable
control that issues notification when pressed and/or released.
- Canvas - Composite
control that provides a surface for drawing arbitrary graphics. Often
used to implement custom controls.
- Caret - An "I-beam" that is typically used as the insertion point for text.
- Combo - Selectable
control that allows the user to choose a string from a list of strings,
or optionally type a new value into an editable text field.
- Control that is capable of containing other widgets.
- CoolBar -
Composite control that allows users to dynamically reposition
the cool items contained in the bar.
- CoolItem -
Selectable user interface object that represents a dynamically
positioned area of a cool bar.
- Group - Composite
control that groups other widgets and surrounds them with an etched
border and/or label.
- Label - Non-selectable
control that displays a string or an image.
- List - Selectable
control that allows the user to choose a string or strings from a
list of strings.
- Menu - User
interface object that contains menu items
- MenuItem -
Selectable user interface object that represents an item in a menu.
- Non-selectable control that displays progress to the user, typically
in the form of a bar graph.
- Sash - Selectable
control that allows the user to drag a rubber banded outline of the
sash within the parent window. Used to allow users to resize child
widgets by repositioning their dividing line.
- Scale - Selectable
control that represents a range of numeric values.
- Selectable control that represents a range of positive numeric
values. Used in a Composite that has V_SCROLL and/or H_SCROLL styles.
- Shell - Window
that is managed by the OS window manager. Shells can be parented by
a Display (top level shells) or by another shell (secondary shells).
- Slider - Selectable
control that represents a range of numeric values. A slider is distinguished
from a scale by providing a draggable thumb that can adjust the current
value along the range.
Composite control that groups pages that can be selected by the
user using labeled tabs.
- TabItem -
Selectable user interface object corresponding to a tab for a
page in a tab folder
- Table - A
Selectable control that displays a list of table items that can be
selected by the user. Items are presented in rows that display multiple
columns representing different aspects of the items.
- Selectable user interface object that represents a column in
- Selectable user interface object that represents an item in
- Text - Editable
control that allows the user to type text into it.
- ToolBar -
Composite control that supports the layout of selectable tool
- ToolItem -
Selectable user interface object that represents an item in a
- Tracker -
User interface object that implements rubber banding rectangles.
- Tree - A
selectable control that displays a hierarchical list of tree items
that can be selected by the user.
- Selectable user interface object that represents a hierarchy
of tree items in a tree.