Java Development with Eclipse
I'm sure many of you are as eager to read about developing Eclipse plug-ins as I am to write about them. But, before you can set out on that exciting trip, you have to take a quick look at what it takes to develop Java applications, in general, using Eclipse. Aside from learning how to use Eclipse's Java Development Tools (JDT), this second installment of my series on Eclipse will help you develop appreciation of the Eclipse Workbench and its various visual components from a user's perspective.
Installing Eclipse is easy. Unpack the downloaded archive into an arbitrary directory in your filesystem. When done, you will find in it a sub-directory called eclipse, which contains the main eclipse executable (for example, on Windows platforms it will be eclipse.exe). Launch it to start the Eclipse Workbench.
To many companies in the software business, Eclipse is a platform (or Rich Client PlatformRCP, to be precise) on which they can base their products. To most Java developers, Eclipse is an Integrated Development Environment (IDE) with which they write Java software on a daily basis. In fact, Eclipse provides support for development in programming languages other than Java, such as C/C++, PHP, Ruby, Python, and more. Even within the Java family, one can write applications that range from J2EE to rich client to embedded.
In this article, you'll briefly examine what it takes to create a Java application in Eclipse. To help you along the way, you'll create a simple console application. Although the outcome is likely to be less than exciting, this exercise will takes you through some of the major concepts and functional groups in Eclipse and its Java Development Tools (JDT).
To follow the discussion in this article, you will need to have the Eclipse SDK 3.1 installed. If you don't have it yet, you can follow the simple instructions provided in the sidebar.
Downloading The Eclipse SDK
To download a free copy of the Eclipse SDK, visit the Eclipse downloads page at http://www.eclipse.org/downloads. The recommended downloadEclipse SDK 3.1displayed prominently in the top section, should be suitable for your particular platform and operating system. If you prefer to choose from all available downloads, click Other downloads for 3.1. Make sure, however, that you download the SDK rather than another, trimmed-down distribution package.
Way of the Workbench
Even before you start writing Java code, you need to familiarize yourself with the Eclipse Workbench and its various elements. This is because the Java Development Tools (JDT), as well as many other Eclipse-based development tools (such as PDE), build upon this framework to deliver their own functionality. As you already know, Eclipse is a component-based platform (components in Eclipse-speak are called plug-ins, or bundles) and Eclipse-based applications (such as the Eclipse SDK) are highly modular. Eclipse SDK itself consists of a mixture of plug-ins, which together make it what it is; other Eclipse-based applications may share some of those plug-ins, but usually bring along their own set of plug-ins that differentiate them.
At a high level, you can think of the Workbench as a window (or a set of windows) around which all of the visual elements of an application are organized. It is the window you'll see when you launch your Eclipse SDK. Not all Eclipse-based applications must necessarily use the Workbench; in fact, it is possible to create "headless" applications that are completely driven from the command-line (or through other, non-visual means). However, complex rich-client applications, such as IDEs, are typically based on the Workbench. (In fact, what you'll see in an IDE is typically the IDE Workbench, a special flavor of the Generic Workbench provided by Eclipse.)
A typical workbench window consists of the main application menu bar, toolbar, an editor area (into which editors may be opened), and several views. The selection of views and their layout within the window is called a Perspective. Perspectives are typically organized around some functional area or user activity, such as Java development, Resource management, and so on, depending on what your application provides. They are completely user-customizable; you can show any views available (click Window -> Show View) and rearrange them in any way you want (use your mouse to drag the view's title bar around the window). To customize the perspective's "Action Set" (in other words, the set of menu and toolbar items), click Window -> Customize Perspective... Many menu and toolbar actions can be invoked using a keyboard sequence, whichyou guessed itis also completely customizable (click Window -> Preferences, then enter your preferences under General -> Keys). When you restart your workbench, all your perspective customizations will be persisted across workbench sessions. You can even save your customized perspective under its own name (click Window -> Save Perspective As...). Figure 1 illustrates a customized layout of the Java perspective.
Other common visual elements you will encounter while working with the workbench are the various types of dialog boxes, or dialogs, for short. You have already seen them if you tried some of the perspective-related menus mentioned above. They are usually modalmeaning that you cannot access any other window or dialog until you close the one that's currently active. Some dialogs take you through multi-step actionsthese are called wizards. The telltale sign of a wizard is the set of Back, Next, Finish, and Cancel buttons at the bottom of it.
Workspace Resource Model
To understand the function of many standard menus and views in the IDE Workbench, you have to take a look at the model that most Eclipse-based tools use when interacting with the filesystem. Elements of this model are referred to as Resources. Resources are organized into a tree hierarchy that very much resembles the filesystem itself. In fact, all Resources are in one way or another linked to a physical filesystem element. The root of this model is called the Workspace. Its main role is to be the singleton instance of the Resource model within the application. It also provides API for workspace-wide management of resources. All Workspace contents are organized into Projects, which in turn contain Folders and Files. The idea behind Projects is to group resources (Files and Folders) that are closely related to each other. For example, the source of a Java application, or a library packaged into a JAR file, may be organized into one project. Projects may be linked together in a dependency graph.
Workspace settings and preferences (including those of all Projects) are stored in a special location in the filesystem called the Workspace location. You were probably asked to choose one right after you started your Eclipse SDK. (You can make your selection default and Eclipse won't ask next time you run it.) This directory contains a sub-directory called .metadata, which is where all plug-ins' Resource-related data is typically stored.
The Workspace location is not necessarily where all Projects physically reside. A Project may be assigned a location outside of the Workspace, which will serve as the root directory for all its Files and Folders. Typically, a File's Project-relative path matches its physical filesystem path relative to its Project's location (in other words, /myproject/myfolder/myfile.txt could map to c:myworkspacemyprojectmyfoldermyfile.txt, where c:myworkspacemyproject is the project's location). However, it is also possible to create links to filesystem folders and files that may reside at a location outside of the Project's subtree.
The Eclipse Resource model also supports the concept of Project builds. Without going into too much detail, plug-ins interested in participating in Project builds must register their Incremental Builder implementations, which will be invoked either directly by the user (through the menu), or automatically when some Resources change. This, for example, is what makes it possible for the Java builder to incrementally compile your Java code. Plug-ins associate their builders with projects by assigning them their Project Natures (for example, a project with the Java Nature has some Java-compilable code, but it could be a simple Java application, an Eclipse plug-in project, an EJB project, and so forth.)