The defining feature of Eclipse 3.1 is full support for Java Tiger (J2SE 5.0). Of course, there are other important features in the project plan for Eclipse 3.1 [1], each affecting a different functional area. After emerging from a diverse array of open IDEs, Eclipse release 2.0 ventured from its native domestic programming field to the project management environments commonly found in enterprise development.
Today, Eclipse’s frontier is that of multi-project architectures, as opposed to mere J2EE frameworks or ubiquitous support for diverse web applications and languages. Developers have always pursued the goal of flexible development. However, there were and continue to be innovations required to realise this dream in the Java developer community. These include releases such as JDK 5.0 and trends stimulated by the new features in J2EE 1.4 and 1.5. Within the Java development environment, Eclipse version 3.0 offered for the first time an abundance of additional features and support for complex details whose neglect often causes the failure of ambitious, large-scale software development projects.
Eclipse 3.1 – Release Objectives
The ongoing, long-term goals of Eclipse releases are stated in its open source project plan, and some of these have been implemented in version 3.1. They include an extended development platform, inclusion of rich client platform models, and an ongoing integration of software solutions contributed to its growing, open source community. Also of interest are version 3.1’s changes in the areas of debugging, Ant support and the development of RCP-based client applications.
Pace to Eclipse 3.1
To install Eclipse 3.1, Java 1.4.1 or higher is required. Those who wish to use the extended language features of Java 5, must download Sun’s 50MB Java VM [2]. With approximately 105MB of zipped up installation files, setup and customisation has not changed much from version 3.0. The standard Windows version is barely 18MB larger than the previous maintenance version 3.0.2.
Java 5 – Language Features
For most users, Java 5 means the inclusion of those additional runtime library extensions which have been incorporated into version 5. These include JMX, along with language features (e.g. static imports, enumerations, generics). Most of these features are of key importance to IDE development teams, who often cannot adapt their IDEs to an already existing and available client VM.
Eclipse, which distinguished itself with strong workflow support, numerous other assistants and compiler settings, has to adapt its compiler, language features and compatibility to JCK 1.5/5.0. That might explain version 3.1’s delayed release, as compiler output was sometimes far from Sun’s standard specifications. Hence, those who wanted to bring enumerations or generics into an application had to accept missing search or refactoring features in their IDE.
Hence, if you wish to use the first language feature, the IDE suggests changing the compiler options, which are adjustable and also declarable for every project. A newly designed property dialogue appears in Preferences dialogue for the first time. The Preference dialogue now offers the ability to filter by keywords through the filter box. Moreover most dialogues are grouped thematically and can be closed separately whenever you need to do so. Besides, the Workbench Preferences dialogue supports a history function for the sites to review private settings. In addition, when switching over to Java 5.0 compatibility, new compiler options can be activated in the Errors/Warnings (e.g. warnings about automatic auto boxing).
Fig. 1: JDK 5.0 – Setting up project preferences
With respect to Eclipse’s new features, compilation can be executed with an old JRE 1.4 compiler, as long as no classes such as java.lang.Annotation or java.lang.Enum come into operation. However, if you are not plugged into 1.4 compatibility, the classloader will fail on initial startup, thereby reporting an unknown class file version.
Consequently, upgrading to version 5.0 requires the exchange of JRE Project in the Project Preferences.
Fig. 2: 5.0 Source with 1.4 Java VM
Eclipse has no problems with features like enumerations, annotations and auto boxing. Annotations and enums are displayed separately in Package Explorer, where they are represented by their respective icons. Obviously, the IDE with Java 5 is intuitively aware of typical, predefined annotations such as @Deprecated, @Documented, @Override, @Target, etc.
While the code assistant can handle enums (which are treated as normal classes internally), including annotations with @ sign, code completion were unmanageable in the latest version.
Indeed, Eclipse even began to transfer the variable values of annotations from the source code into file properties in an externalisation process. Hence, the syntax of classes was so affected that they were no longer capable of compilation. However, these visible bugs should be fixed in the final release.
Fig. 3: J2SE 5.0 extensions of source code
The much discussed and reliably far reaching language extensions might be generics in Java 5. Different views, as well as the dialogues, are aware of the generic syntax and can interpret it. Of course, it remains to be seen whether Generics will revolutionise the Java world or suffer delays in examples and usage in a way that is often typical of collection elements. However, it must be said that at the very least, Eclipse supplies an essential basis for development with generics.
Fig. 4: Java generics
Now, new templates and code assistants are at the disposal of the most available program constructions, such as for-each loops or an abundance of generically supported collections. In version 3.1, the editor resolves arguments, which come up in typical collections (eg. JAVA/EDITOR/CODE/ASSIST/ADVANCED/GUESS FILLS ARGUMENT NAMES). Those interested in getting acquainted with these new programming constructions can refer to a review of source document recommended here [4].
Migration from 1.4 to 5.0
As is often the case with new language features, we face the problem of legacy code. Hundreds and thousands of source code lines pay regard either to parameterised types or new for loops. The new keyword “enum” is an addition to the old version of Java, and is an entirely acceptable variable name before merging into Java’s syntax. When using the keyword “enum”, Eclipse 3.1 now presents warnings in the existing 1.4 legacy code. If you give such a name, you can expect a corresponding warning notice during the importing source code into Eclipse.
Version 3.1 allows the conversion of old for loops into new for loop variants, and also comes with a Quick Fix tool. The latter can be activated through CTRL + 1, when the cursor is inside the loop. Eclipse 3.1 automatically sets type suggestions for the available new collections, to ensure its type safety in the future. For legacy code, there are plenty of warnings in source, which point to non-typical list operations, if the right compile options are set up.
Fig. 5: Quick fix for for loop
Fig. 6: Warning for non-type-safe lists
Adaptation to the Tiger
In the case of refactorings, typical actions such as removing classes and methods, extraction of subclasses/interfaces, pulling up of methods in the class hierarchy or extracting program structures also support the new language constructions. New Quick Fixes are aware of available corresponding Javadoc tags and new Java 5.0 practices.
Multi-project Management
As mentioned, besides supporting Java 5, an essential feature of Eclipse 3.1 is its enhanced capability for handling larger, more complex projects. Apart from filtering Preference dialogue contents, the management of Eclipse projects has also been improved.
Projects could already be grouped into working sets in the previous 3.0.2 version. Those with several projects to process in parallel can group individual projects, as well as blend them together or separate them, depending on one’s needs. The latest release extends this ability by importing a number of files and projects into Eclipse at the same time.
Moreover, Eclipse shows a further useful function in its Import wizard for existing source code. The handling of include and exclude settings for the project has been considerably simplified. Now, tables in the Package Explorer can be mobilised fast and without any problems. Furthermore, attributes of such files (e.g. read only, executable, archive, derived) in the project can also be modified.
Fig. 7: Exclusion of lists
These Preferences allow themselves to be exported or imported for exchanging properties of individual projects. Before version 3.1, this could only be done through the Workbench for the entire project. These functions may also be performed on projects with many developers managing common settings and wanting to exchange. Besides, non Windows users now enjoy extended support for .tar and .gz files, as support is extended beyond .jar-and .zip formats.
Finally, we come to the support for business software development. Have you ever perceived in your design analysis a strict separation of service or public classes? For that, Milestone 3 initiates an access restrictions test. Individual packages of libraries are separated pattern wise (e.g. ** /impl **) and supplied with corresponding warnings in the Java compiler settings (JAVA|COMPILER|BUILD PATH|ACCESS RESTRICTIONS VIOLATIONS).
Debugging Features
You will find a few notable novelties in the area of debugging. As an Eclipse user, you are surely aware of the occasionally bothering presentation of variables at run- and debug-time. If you think of examples like Swing classes, which come from JFrame or JPanel, hundreds of variables exist besides the few, which are really relevant to your own work. In debugging, you can now define the logical structure of intimated objects. In addition, redefinitions of classes like String are also possible.
You define a kind of mapping between the output class (and if desirable, all relevant subclasses) and the new declarations of the variables in the view. You may experience a similar redefinition of toString() invocations in the preceding versions of Eclipse. Hence, the declaration of complex classes is modified to reflect the naming of new individual variables and their assignments of corresponding Java statements.
Fig. 8: Definition of a logical structure
Similarly, as project complexity increases, you can lose sight of those breakpoints that have been set. The concept, which was devised from Eclipse developers, is similar to the management of Eclipse projects. Now, breakpoints can be grouped into different criterion or interlocked (e.g. according to projects or the break point type) and organised in work sets. Therefore, multiple breakpoints can be deactivated or removed simultaneously.
With J2EE’s complex application cases and numerous threads, a debug extension could prove very helpful, which so far has been found in the profiling area. Through the Show Monitor Setting, the debug view now displays objects which have been locked by a thread. In this way, version 3.1 allows deadlocks and critical synchronised spots to be traced easily. Deadlocks or long waiting times are common in a multi-thread environment, particularly on neuralgic source code points (hotspots).
Debugging output, which hitherto was presented on the console view can now be made persistent to a file by setting a property in the launch configuration. This simplifies the redirection of System.out/System.err in a file when a logging tool like Log4J is used.
Interior of an Ant
In version 3.1, modifications have also been undertaken with respect to the Ant tool. For more flexibility, the Ant editor has been augmented in the new Eclipse version. While folding to understand the build.xml files seems to be a nice-to-have feature here, Eclipse now realises that Ant and its XML can become parts of a programming language. The outcome of this effort is full debug support. Meanwhile, breakpoints can be set in a build file, and the debugger answers it by opening a debug perspective in which the states and values of environment variables are displayed.
There is no doubt that these functions were incorporated to address the needs of large, ambitious software development projects. Home programmers and developers with adhoc programming techniques might find the JAR file export feature a flexible tool too.
Fig. 9: Ant debugging
Nice to Have
In addition to support for Java 5, there are changes in this Eclipse version which some may view as "nice-to-have", while other developers would consider essential and invaluable. These include support for externalised texts in the area of Install/Update features of IDEs, which help in the generation of the UIDs for serialisable classes or objects.
Whenever a programmer leaves the world of Java syntax, externalised texts and configurations are an inherent problem. Besides, issues arise when using configuration sources like files or databases; particularly with respect to whether certain key value pairs are still in use. Those who have deposited strings by means of Eclipse in a property file can now navigate backwards and forwards using the CTRL-button. You can click on the key in the Java source code or in the NLS-ASCII file to switch between both references. However, for those who compose the property NLS names dynamically, this reference search capability is obviously of limited value.
In addition to the NLS theme, it is noted that if there is a tab in the search dialogue, which is used to trace NLS keys. It does this by concentrating on corresponding key value pairs while searching for the entire text’s algorithm, thereby tracking down lost sites in thousands of Java data and Javadoc commentaries.
There is a change even in the area of installation. Functions for updating and installating new eclipse plug-ins have been dramatically improved over past versions. Eclipse now supports the background downloading of plug-ins.
Version 3.1 also addresses the search for mirror and FTP sites, along with their authentication handling. This may be interesting for those who frequently download plug-ins from the internet or have to update their plug-ins from intranets. However, despite this innovation, other issues still remain – smooth installation or compatibility with existing plug-ins is not guaranteed.
Likewise, the ability to test serial classes on the existing UID variable is an improvement. Such class variable is set via a Quick Fix into a java.io.Serializable implementing class. We remember however, that the UID serves as a unique class descriptor when exchanging objects between client and server. The UID is used in Java’s remote invocation process and built over non-transient class attributes that are delivered within a network. Quick Fix allows the setting of a simple 1L-Long or computation of a representative UID value. However, this still assumes that the class structure does not change.
Dictionaries, Help and CVS
In Eclipse 3.1’s dictionaries and spell checks for Javadocs, even though thesaurus and grammar tests are still not incorporated, there is now a textual test for NLS files. Java help is also available instead of an individual help browser within a perspective view. This search engine supports typical actions like chapter search, and searches over the entire Workbench. Depending on your needs, these searches can go beyond incorporating mere local help data, and their scope can include contents from the Eclipse.org site, as well as Google searches.
There are also minor adjustments in Eclipse’s CVS support like improved identification of data types, key bindings, and the ability to review data found in branch and merge actions.
Furthermore, version 3.1’s numerous, increasing number of keyboard shortcuts can be reviewed by pressing CTRL + SHIFT + L. This new facility will be handy to experienced users and novices alike.
Fig. 10: New online help
New Toy for Plug-in Developers
Even in the realm of plug-in development, few things have been changed. A self-driven SWT Startup configuration, and improved support for the development of RCP applications (e.g. through predefined templates) enable Eclipse developers to more efficiently chart the development of their project.
Moreover, a steadily rising number of Eclipse partners like Borland have supported this trend in recent months. The strongly revised and extended documentation of platform – developer guide now includes areas such as key bindings, light weight decorators, image caching, etc. Take a look at the latest online documentation available for further information on the plug-in development.
Eclipse Projects
When speaking of Eclipse, you must always bear its large open source community and ever expanding pool of plug-ins in mind. Most developed plug-ins are available over the internet, though a few key Java vendors have also added their support to Eclipse’s growing community. In addition to the Eclipse project, you must not forget the numerous tools projects, for example, the ongoing development of a Cobol IDE or support for Swing/SWT in the Visual Editor (VE), as well as emerging web tools and Test/Performance Projects. These will be gradually adapted to support Eclipse 3.1 and the Java 5.0 IDE over the coming months.
To Upgrade or Not?
Ultimately, a recurring question remains: should I upgrade now? As usual, the answer depends on your personal requirements. If you are an experienced and satisfied Eclipse 3.0 user, you may not have pressing motivation to migrate to version 3.1 at this time. On the other hand, all the features described in this article can make the transition from 3.0 to 3.1 more meaningful, particularly if you intend to use Java 5, work in large, multi-project-environments, complex applications or employ multi-language support.
Lars Wunderlich is an author and software developer. He is currently involved in building enterprise applications and employed as System architect and Software Engineer at TUI Info Tec GmbH, Germany.
Links & Literature
[1] www.eclipse.org/eclipse/development/eclipse_project_3_1.html
[2] java.sun.com/j2se/1.5.0/download.jsp
[3] Friedrich Esser. The Tiger release: Java 5 in operation, Galileo Press, 2004; respectively
Ulrike Böttcher, Dirk Frischalowski: Java 5- Handbook for programmer and professional use,
Software and Support Edition, 2005
[4] java.sun.com/j2se/1.5.0/docs/relnotes/features.html |
