Eclipse 3.1 - New and Noteworthy

JDT


J2SE 5.0	Eclipse 3.1 includes full support for the new features of J2SE 5.0. This support is both pervasive and powerful -- everything that you expect to work with J2SE 1.4, including editing, code assist, compiling, debugging, quick fixes, refactorings, source actions, searching, etc. will work seamlessly with (and has been extended to support the new capabilities of) J2SE 5.0's new types and syntax. Here are some examples: Quick Fix to update JRE and compiler compliance to 5.0 New Type wizards support generics Enumeration and Annotation wizards Semantic coloring of J2SE 5.0 constructs in Java editors Rename refactorings handle renaming of type parameters Infer Generic Type Arguments refactoring Quick fixes for Generics Search result filters for reference search for parameterized types Code completion for annotations @SuppressWarnings annotation support optional diagnoses for issues such as incomplete enum switches and boxing/unboxing conversions Quick Fix to create enum constants Autoboxing parameter proposals Quick Assist to convert for-loops over arrays and collections to J2SE 5.0 enhanced for-loops Support for package-info.java Please check out the Java Development User Guide help book (available from the Help > Help Contents menu) for more details on the many new J2SE 5.0 specific features that have been added. In order to develop code compliant with J2SE 5.0, you will need a 5.0 Java Runtime Environment (JRE). If you start Eclipse for the first time using a 5.0 JRE, then it will use it by default. Otherwise, you will need to use the Installed JREs dialog to register one with Eclipse. You can reach this dialog either via the preference Java > Installed JREs or by following the Configure default... link on the New Java Project wizard.

New Javadoc compiler settings	When Javadoc checking is enabled, you can configure it to warn when `@see` and `@link` tags reference deprecated elements warn when `@see` and `@link` tags reference elements that are not visible The settings are on the Java > Compiler > Javadoc preference page.

Serial Version UID	There is a new optional compiler diagnosis for serializable classes missing a declaration of a `serialVersionUID` field. The preference setting can be found at Java > Compiler > Errors/Warnings > Potential programming problems

Early detection of references to internal classes	You can annotate library (and project) entries on the Java build path (Properties > Java Build Path > Libraries) to identify any internal packages that you want to avoid referencing directly from your code. For example, it's generally a bad idea to depend on any of the vendor-specific packages, like `com.ibm.` or `com.sun.`, commonly found in the J2SE libraries. Access restrictions are expressed with a combination of inclusion and exclusion rules on build path entries. The pattern syntax follows Ant fileset notation, and matches against the path to the class file. For example, using the pattern `com/ibm/` as an exclusion rule would restrict access to all classes in the `com.ibm` package and its subpackages; using the pattern `org/eclipse//internal/` as an exclusion rule would catch all classes to internal Eclipse packages. When you provide inclusion rules, everything matched by these rules is ok, and everything else is considered out of bounds. The Java > Compiler > Errors/Warnings > Deprecated and restricted API** preference setting lets you control whether errant references are flagged as errors or warnings (they are errors by default for forbidden reference and warnings for discouraged references).

Access rules on libraries and projects	Access rules can be defined on referenced libraries and projects to explicitly allow/disallow/discourage access to specific types.

Mark occurrences of inherited methods	The Java editor can highlight all method declarations that implement or override methods inherited from the selected supertype. See the Java > Editor > Mark Occurrences > Method implementing an interface preference setting.

Highlighting of deprecated class members in the Java editor	Deprecated class members are marked by advanced highlighting: This is configurable on the Java > Editor > Syntax Coloring preference page.

References in Javadoc	Eclipse now recognizes references to Java elements inside doc comments (i.e., @see, @link, @linkplain, @throws, @exception, @param or @value tags). This enables hover help and linking to the referenced Java element.

Improved Java properties file editor	The editors for Java property files have been greatly improved. They offer syntax highlighting, improved double-clicking behavior, and a separate font preference. The syntax highlighting colors are adjusted from the Java > Properties File Editor preference page. Spell checking is available, and Quick Fix (Ctrl+1) can be used to fix spelling problems. You can also use Navigate > Open (F3) or Ctrl+Click to navigate from a property key in the editor back to places in the code where the key is referenced.

Working with externalized strings	When you linger over a key for an externalized string in the Java editor, the associated externalized value is shown in a hover: Ctrl+Click on it to navigate directly to the entry in the corresponding Java properties file.

Externalize Strings wizard supports new message bundles	The Externalize Strings wizard supports Eclipse's string externalization mechanism which is new with this release:

New Open Type dialog	The Java Open Type dialog has been improved in a number of ways: There is now only a single list to select from. A history of recently opened types shows up first in the dialog; workspace types matching the pattern appear below the separator line. CamelCase pattern matching takes you to a type with fewer keystrokes. For example TZ matches TimeZone or IOOBE matches IndexOutOfBoundsException. The content of the dialog can further be constrained to a working set. The working set can be selected from the dialog's drop down menu. There are major architectural changes under the hood as well. The types shown in the dialog are now found with a Java search engine query. This nets a saving of 4-6MB on a normal Eclipse development workspace over the memory-hungry approach used previously.

Previous Next