Up to this point, we’ve hinted at how the Eclipse IDE can be your one tool for the whole development process. This seems quite a bold claim, but it is very much a reality with Eclipse thanks to its forward‑thinking architecture.
By itself, the Eclipse Platform does nothing. The core piece of Eclipse is just a small kernel called the Platform Runtime. All functionality of the IDE is a result of interactions between the plug-ins and the kernel. When you launch the Eclipse executable, the kernel checks what plug-ins are available in a special plug-ins directory. Each plug-in has a manifest file that defines how it interacts with the Platform and with other plug-ins. To save startup time and system resources, each plug-in is loaded only when necessary.
The manifest file is XML based and defines the extension points used by the plug-in. Extension points are the basis in communications between plug-ins and the Platform. An extension point either declares the services this plug-in can provide to other plug-ins, or declares how this plug-in will interact with another plug-in’s extension point. This leads to a very interesting behavior of Eclipse. With plug-ins themselves being extensible, the lines often blur between plug-ins. When we actually start coding in PHP, we’ll see how tools in the JDT are extended via the PHPEclipse plug-in. For example, the same tool that is used to show an outline of all functions in a Java class is also used to show PHP functions once PHPEclipse is installed.
When you download the full Eclipse SDK, it includes several plug-ins that give it all the features of an IDE —workspace, Workbench, the JDT, Version and Configuration Management (VCM) system, the help system, and the PDE.
Each application you develop in Eclipse is organized as a project. Each project may hold different files, directories, and settings. The workspace not only manages where the resources are, but also manages the state of resources. Each resource may hold a historical record of changes and other resources might be interested in this information. The workspace coordinates all of these things between resources.
The Workbench is essentially Eclipse’s GUI. From menu items to window panes to buttons, the Workbench handles everything you see and interact with. The Workbench is written in the Eclipse Standard Widget Toolkit (SWT) and JFace. We’ll discuss the SWT and JFace in depth later. Basically, like Java’s native Swing, both are Java GUI libraries. Like the Workbench and everything else, SWT and JFace are plug-ins that are loaded by the runtime kernel.
Since Eclipse made its name as a Java development platform, the JDT (a Java development plug‑in) is included with the standard Eclipse SDK download package. Eclipse’s knowledge of Java syntax, compiling, and debugging come from the JDT. A lot of people do not need Eclipse to do anything more than to be a Java IDE. The JDT is what makes Eclipse a Java IDE.
Version and configuration management system, or more commonly referred to as the Team Tools, manages source code shared by a team. Essentially, the Team Tools allow Eclipse to act as a full Concurrent Versioning System (CVS) client. By talking to the Workbench plug-in, the Team Tools know what files need to be committed and where to place updated files. Branches, tagging, and patches are also managed by the Team Tools. Do not worry if none of this makes sense. We’ll explore more about versioning and CVS inChapter 7.
The help system makes it easy for plug-in developers to create help files and documentation for end users. All the developer needs to do is create the help files in HTML and define the schema using XML. Through the help system, Eclipse pulls in the help file appropriate to the plug-in when requested by the end user.
Finally, in a seemingly circular relationship, the PDE, the tool to create plug-ins, is itself a plug-in. Development and deployment of plug-ins require meticulous attention to detail. The manifest and source code files can grow quite large. The PDE automates much of this work through wizards, templates, and Eclipse’s own workspace. Thanks to the PDE, it is no surprise that there is a large community of Eclipse plug-ins and plug-in developers. Having a native tool builder within the tool lets anyone alter Eclipse to their own individual liking.
|
Eclipse plug-in development is a very rich subject. Entire books have been devoted solely to this topic. Be aware that Eclipse plug-ins are written solely in Java using SWT and JFace. |
For PHP development, we will be using the PHPEclipse plug-in. This third-party plug-in fits nicely into the Eclipse architecture as can be seen in the figure below which shows the Eclipse Platform architecture:
Now that we know the roles and workings of plug-ins, the Workbench plug-in deserves a little bit of extra attention. The JDT and PDE plug-ins rely on the Workbench’s extension points, but not vice versa. If you do not require Java development tools, you can conceivably download just the Eclipse Platform. The Eclipse home site ( http://eclipse.org/downloads/) offers downloads of the Platform without the JDT and PDE plug-ins.
The text editor functionality is in the Workbench. These ‘platform-only’ downloads would have the editor without any sort of indication that this is a Java IDE. The three other ‘core’ plug-ins (help, workspace, and Team Tools) would also be present. However, Eclipse’s functionality would certainly be limited.
The primary purpose of having downloads without the JDT and PDE plug-ins is to allow redistribution and repackaging of Eclipse. If your product involves Eclipse but not Java, you can release a version without the JDT. Another purpose may be to speed up the start-up time and performance of Eclipse. Indeed, the smaller the number of plug-ins that are installed, the faster Eclipse starts up.
The story of the SWT is certainly the most controversial part of the development of Eclipse. SWT does the actual illustration of the Eclipse GUI. Buttons, checkboxes, windows, and the like are all handled by the SWT. If you want to draw a radio button inside a box in a plug-in, you use SWT’s API to do so. In fact, we can use SWT as the basis of the GUI for any Java desktop application.
On the other hand, we have Swing. Swing is the official collection of Java classes used to build user interfaces, objects like windows, text boxes, and such. Swing and SWT sound a lot alike. In fact, you might say it sounds like SWT replaces Swing in Eclipse, and you’d be right. In developing Eclipse, IBM bypassed the officially blessed GUI toolkit and created its own. Needless to say, Sun is not very happy with this, and this is perhaps a reason why Sun, the creator of Java, does not hold, and has never held, any role in the Eclipse Foundation.
SWT integrates much closer to the native operating platform than Swing. For each platform that SWT runs on, the libraries hold a direct mapping from the SWT Java calls to the target platform, which are written in C. Unlike Swing, the JVM does not have to do this mapping. This gives SWT applications a speed advantage when dealing with GUIs. The performance of SWT applications is close to OS-native applications. For common widgets like radio buttons and text boxes, SWT uses the operating system’s native widgets. Only if a widget is not defined will SWT emulate the widget. An SWT-based application running on Windows XP will look like a Windows XP program. The same program will look like a Mac OS X program when running in Mac OS X.
There are downsides to SWT. First and foremost, by integrating tightly with platforms, the interface loses its consistency, and Java applications potentially lose their portability. Each platform requires its own SWT library, and platform-specific code can be written in each one. This opens the door to platform-specific Java, which is philosophically against Sun’s promise of keeping Java platform independent. Since it’s not an officially blessed specification, SWT applications are breaking a standard. If you decide take a side in this issue, be aware that you’re entering a furious religious debate.
|
There are technical downsides to SWT too. Since SWT interaction does not happen in the JVM, developers cannot rely on Java’s garbage collector to destroy objects. You’ll have to be vigilant and do this yourself. Swing also employs a pluggable architecture, which you will lose with SWT. |
IBM was well aware of the tradeoffs when creating SWT. In the end, we can’t argue with the results. If you have ever used a Swing-based desktop application, you would never guess Eclipse was written in Java. Eclipse is a fast and cross-platform application that aesthetically looks good. Pre-compiled binaries are available for all major operating systems including Mac OS X, Linux (GTK and Motif), Windows, and Solaris. SWT makes Eclipse fast and cross platform.