Here are some of the more interesting or significant changes made to the Java development tools for the 3.0 release of Eclipse since 2.1:
Folding in the Java editor | The Java editor now supports folding of code regions. Hovering over a
folded Java element lets you peek at the hidden code:
Currently, import statements, comments, types and method bodies can be folded. Whether folding should be enabled on new editors can be configured on the Folding tab on the Java > Editor preference page:
|
Advanced highlighting | The Java editor can now highlight source code according to its
semantics (for example: static fields, local variables, static method
invocations). When advanced highlighting is enabled via the Java >
Editor > Syntax preference tab, the new advanced highlighting
options show up in the list.
There are also new options for highlighting operators and brackets, and Italic is a newly supported style. |
Quick type hierarchy view | Select a type, method, or package reference in the Java editor and
press Ctrl+T to see a quick type hierarchy view. For methods, you see
all subtypes and supertypes that provide this method.
Repeat CTRL+T to toggle between the normal type hierarchy and the supertype hierarchy view. |
Quick Outline shows inherited members | The quick outline (Source > Open Outline, Ctrl+O) in the
Java editor now shows inherited members after repeating the key sequence
Ctrl+O:
Likewise for Quick Structure (Ctrl+F3). |
Smart Insert typing mode in Java editor | The Java editor now has a Smart Insert mode which can be toggled via Edit > Smart Insert Mode
(Ctrl+Shift+Insert).
In Smart Insert mode, the editor provides Java-specific extras which can be configured on the Java > Editor > Typing preference tab. The Smart Semicolon and Smart Opening Brace options for example move the caret to the end of the line before inserting the semicolon or closing brace, respectively. |
Update imports on paste | Copying or cutting Java code also captures information about which import declarations are needed by the copied code. The needed imports are now added automatically when the code is pasted. This feature can be configured with the Java > Editor > Typing > Update imports on paste preference setting. |
Improved cursoring through Java names | The Java editor's word-at-a-time actions now respect the typical "CamelCase" notation of Java identifiers. For example, Next Word on the identifier "getFoo" makes an additional stop between "get" and "Foo". Cursoring behavior for Java names is controlled by an option on the Java > Editor > Navigation preference page. |
New code formatter |
The Java code formatter has many improvements to offer: The Java > Code style > Code Formatter preference page lets you choose from existing profiles, define your own, and share them with others. The new formatter is highly configurable, with over 140 options covering everything from brace positions to wrap lines up to Javadoc comment formatting. |
Format multiple files | The Format command is also enabled on Java projects, source folders, and packages. When invoked, all contained source files will be formatted according to the currently configured formatter settings. |
Spell-checking | Spell-checking support has been added to the Java editor. After
enabling it and specifying a dictionary on the Java > Editor >
Spelling preference page, spelling errors are displayed in the Java
editor and corresponding Quick Fixes become available.
Optionally, you can make the dictionary available to the content assist. However, there is currently no dictionary included in Eclipse. The required format is just a list of words separated by new line characters and the Quick Fixes allow you to add new words to the dictionary on-the-fly. Contributions of dictionaries would be welcome. |
Block commenting | A text selection in the Java editor can be quickly turned into a block comment using Source > Add Block Comment. Conversely, the Source > Remove Block Comment command removes the block comment enclosing the cursor position. |
Toggle Comment command | The old Source > Comment and Source > Uncomment commands in the Java editor have been replaced by the Source > Toggle Comment (Ctrl+/) command that uncomments the currently selected source lines if all of them are commented and comments them otherwise. (You can bind keyboard shortcuts to the old commands, which are still available, via the Workbench > Keys preference page.) |
Incremental content assist | Check Insert common prefixes automatically on the Java > Editor > Code Assist preference tab to use shell-style incremental completion in the Java editor. If the available completions do not have a common prefix, the proposal pop-up is displayed. |
Dynamically marking occurrences in file | Occurrences of the selected element can be marked in the Java editor
with the new Mark Occurrences toolbar button (
) or command (Alt+Shift+O). On the Java > Editor > Mark
Occurrences preference page, you can configure the elements to be
marked.
The occurrences of the selected element are marked using Occurrences
annotations, whose presentation can be configured using the Annotation
preference page (Workbench > Editors > Annotations).
When the selected element changes, the marked occurrences are automatically updated. By default, marked occurrences are sticky, i.e. remain highlighted even when there is no valid Java element at the current caret position. Marked occurrences can quickly be removed using the Remove Occurrence Annotations source command (Alt+Shift+U). |
Highlight method exit points |
Placing the cursor on the return type of a method highlights all method exit points. Highlighting exit points can be enabled via the preference Java > Editor > Mark Occurrences. |
Mark locations of thrown exceptions | When an exception is selected, places where that exception is thrown can be marked in the Java Editor by triggering the action Search > Exception Occurrences. The places are marked automatically if occurrence marking is turned on via the Java > Editor > Mark Occurrences preference page. |
Java editor shows overridden methods | The new Override Indicator annotation (see Workbench > Editors > Annotations preference page) flags a method that implements or overrides another one. By default, override and implements icons appear in the left-hand vertical ruler; click on the icon to navigate to the super method: |
Multiple annotations shown in roll-over hover | When multiple annotations are displayed in the text editor's ruler, they are displayed side by side when hovering over them. Warnings and actions, such as quick fixes, setting breakpoints, and adding bookmarks, can be accessed separately. This functionality is disabled by default, but can be enabled on the Java > Editor > Hovers preference tab. |
New Quick Assist cue | As you type in a Java editor a Quick Assist cue (green light bulb) appears in the left margin when there's a Quick Assist available. Use Edit > Quick Fix (Ctrl+1) or click on the light bulb to see the proposals. This feature can be enabled by checking Lightbulb for quick assists from the Java > Editor > Appearance preference tab. |
Linked mode for Quick Fixes | Several Quick Fix results now appear in linked (template) mode. Use
Tab and Shift+Tab after the invocation of a Quick Fix to navigate
between a generated return type, method name, argument types and
argument names. Examples of Quick Fixes using the linked mode:
Example of argument guessing: Example of exception guessing: |
Improved identifier guessing | When adding fields, variables or parameters, quick fixes try to guess
good names for new identifiers. Using the new linked mode feature, more
than one suggestion is now offered . |
Improved Quick fixes for parameter mismatches | Several new Java quick fixes for mismatched parameters have been added, including offers to cast, swap, add, or remove arguments or method parameters. |
New Quick Assists | New Quick Assists have been added to the Java editor. Try Ctrl+1 on
|
Create getters and setters with code assist | Aside from creating overriding methods, code assist also offers to create getters, setters, default constructors and method stubs. Set the cursor in the type body between members and press Ctrl+Space to get the proposals that create a method stub. |
Fast ways to create a constructor | The new Java command Source > Generate Constructor using Fields
creates a new constructor that initializes selected fields. You choose
the fields to be initialized from extra constructor parameters whose
order is controlled via up/down buttons in the dialog.
The Source > Add Constructors from Superclass command now pops up a dialog so that you can choose which of the superclass's constructors should be inserted into the current class. The quick assist feature can still be used to insert without prompting. |
Pop-ups for inspect/display |
Evaluation pop-ups are now used for all Display and Inspect results. |
Logical Structure |
The Java debugger now allows
certain Java types, including collections and maps, to be displayed in a
more compact and meaningful form. These logical structures are
controlled by a toggle button in the Variables view. |
System thread filter |
System threads are now filtered out from the Debug View by default. The Show System Threads command in the view's drop-down menu toggles the filter on/off. |
Step Into Selection on any line |
The Java debugger's Step Into Selection command is no longer restricted to the currently executing line. |
Class prepare breakpoints |
Breakpoints can be set on a class prepare event. The program will be suspended when the specified class or interface is first loaded by the Java VM. |
Exception breakpoint hyperlinks |
Exception breakpoints can be now created directly from a stack trace in the console. Clicking on the hyperlink that appears under the exception name at the beginning of a stack trace opens a properties dialog on the newly created (or already existing) exception breakpoint. |
Breakpoints in external source |
You can now put a breakpoint in external source code (i.e., source code that is not on the build classpath of a Java project). The breakpoint creation actions on the Run menu automatically create external breakpoints whenever the debugger is displaying external source. |
Refactorings update breakpoints and launch configurations |
Breakpoints and launch configurations are now updated as a consequence of Java source code refactorings such as renaming a Java project, source file, or type declaration. |
Restart option when hot code replace fails |
When changes are made in the host Java VM that hot code replace does not support, you now have the option to Restart the VM in addition to choosing Continue or Terminate. |
Default VM arguments can be associated with a JRE |
The Java > Installed JREs preference page now lets you associate a set of default VM arguments with each JRE. These arguments will be passed to the VM whenever it is used. |
Quick menus for source and refactoring actions |
The refactoring and source commands can be accessed via a quick menu. Select the element to be manipulated in the Java editor or in a Java view and press Alt+Shift+S for the quick source menu or Alt+Shift+T for the quick refactor menu. |
Refactorings update references in Javadocs | Rename, Move, and Change Method Signature refactorings now update
references in Javadoc comments too. This includes references in @see
and @link tags, as well as @param and @throws
clauses.
The Rename dialog has been simplified as a consequence: The old option Update references in Javadoc comments has been folded into Update references. The old options Update references in regular comments and Update references in string literals have been merged into Update textual matches in comments and strings. |
Generalize Type refactoring | Select a declaration of a variable, parameter, field, or method return
type in a Java editor and choose Refactoring > Generalize Type.
The wizard shows the supertype hierarchy for the variable. Selecting one of the available types updates the declaration. |
Introduce Factory refactoring | Select a constructor declaration or call in the Java editor and choose
Refactoring > Introduce Factory.
A static factory method is created that calls the now-private constructor, and all calls to the given constructor are replaced with calls to the new factory method. |
Introduce Parameter refactoring | Select an expression in a Java editor and choose Refactoring > Introduce Parameter. The containing method is given a new parameter and the selected expression is copied to the argument list of all the call sites. |
Improved Change Method Signature refactoring | In the Java editor, select a method and choose Refactoring >
Change Method Signature.
The refactoring now
Furthermore, editing in the parameters table has been streamlined such that you can use standard navigation keys (Tab, Shift+Tab, Arrow Up & Down). Editing can be started by clicking into a cell, or pressing F2 or Enter. |
Extract Method from inner types |
For Java code contained in an anonymous, local, or non-static member type, the Extract Method refactoring now allows the new method to be created in an outer type. |
Extract method finds duplicate code fragments |
Extract method now finds duplicate code fragments and helps extracting them into the new method as well. For example, when extracting the expression foo(a) + bar(b) from the snippet: the resulting code is: |
Method call hierarchy | You can open a view that shows a method call hierarchy by choosing Navigate > Open Call Hierarchy (Ctrl+Alt+H) in the Java editor or any of the Java views that show methods. |
Javadoc view | There is a new Javadoc view (Window > Show View > Other > Java > Javadoc) which shows the Javadoc of the element selected in the Java editor or in a Java view. The Javadoc view uses the SWT Browser widget to display HTML on platforms which support it. |
Declaration view | There is a new Declaration view (Window > Show View > Other > Java > Declaration) which shows the source of the element selected in the Java editor or in a Java view. |
Type filters |
The set of types that show up in code assist and quick fix proposals can now be filtered using the new Java > Type Filters preference page. Types matching one of these filter patterns on the list will not show up in the Open Type dialog, and will not be available in quick fix and code assist proposals. These filters do not affect whether the types show up in the Package Explorer and Type Hierarchy views. |
Improved filtering support | Java-specific view menus which contain a "Filters..." entry now contain adjacent checkable entries for recently changed filters. |
External Javadoc out of archives | If you have Javadoc documentation stored in an archive, you no longer
need to unpack the archive. The Javadoc location property dialog now
supports documentation in archives. Select a JAR and bring up its
property page (or equivalently Project > Properties
> Java Build Path > Libraries > Javadoc
location) to attach documentation to a JAR.
Use Navigate > Open External Javadoc (Shift+F2) to open Javadoc in a browser. |
Grouping options in search view | You can switch the new Search view to flat or hierarchical layout mode in the view menu. Java search results in hierarchical mode can now be grouped by project, package, file, or type. |
Match filters in Java search | Java search results can be filtered. You can filter out Javadoc comments, import statements, read accesses, and write accesses. Only filters applicable to the current search will be shown. |
Search local and anonymous types | Local and anonymous types are now fully supported in search operations. In particular, you can now search for references to a selected local type. Also, search results are now properly rooted inside local or anonymous types (instead of always inside the outermost enclosing method). |
Local types | Local and anonymous types now show up in the various Java-specific views by default, along with filters on the views to hide them. |
Deprecated elements | Types, fields and methods marked as deprecated are now rendered with a slash. |
References in Javadoc comments | The Java infrastructure now includes references in Javadoc comments. You can see this in several places, including Search, Organize Imports, linked renames in the editor, and editor occurrence markers. |
Content assist in dialog fields | Content Assist (Ctrl+Space) is now also available in input fields of various Java dialogs. Look for small light bulb icon beside the field when it has focus. |
Working sets support in Type Hierarchy view |
The Type Hierarchy view now supports filtering by a working set. Once a working set is selected in the view menu, the hierarchy view only shows Java types contained in the given working set, extended by parent types needed to complete the tree (the latter are shown with white-filled images). |
Interfaces in package type hierarchy | The type hierarchy opened on packages (F4) now also shows interfaces of this package. Same for hierarchies on source folders, projects, and JARs. |
Improved NLS wizard | The NLS wizard (Source > Externalize Strings) has been
updated to work on already externalized files:
|
User-defined libraries | You can now group external JARs into a named library. Create
user-defined libraries on the Java > Build Path > User Library
preference page, and then add them to the build path on the project's
properties.
Similarly to class path variable entries, the class path entry for a user library references user libraries by name (not to the JARs to the local file system). |
Eclipse Java compiler is JCK1.4a compliant | The Eclipse Java compiler in 1.4 mode is JCK1.4a compliant; in 1.3 mode it is JCK1.3a compliant. |
Inclusion pattern for source folder | Any source folder on the Java build path can now be associated with some inclusion patterns, so as to selectively include some Java source files. This is complementary to exclusion patterns already available for selectively excluding certain source files. Note that both can actually be combined under the following rule: if you specify both, an exclusion pattern always take precedence over an inclusion one. E.g., {include="src/", exclude="src/sub"} denotes the 'src/' tree without the 'src/sub/' subtree. The include and exclude patterns can be specified via the project's build path property. |
Find indirect access to static members in Java code | The Java compiler can now find and flag indirect accesses to static
members. The option to turn this checking on is found on the Java
> Compiler > Style preference page (by default they are not
reported).
Indirect access to static members is a compatibility issue for generated class file. For class files compatible with JDK versions prior to 1.2, the compiler resolves indirect static references to the declaring class (Y in the example); for class files compatible with JDK versions since 1.2, the compiler resolves static references to the type of the receiver (X in the example). |
Find accidental boolean assignments | The Java compiler can now find accidental boolean assignments.The option to turn this checking on is found on the Java > Compiler > Style preference page (by default they are not reported): |
Java compiler option for flagging unqualified instance field accesses | The Java compiler can now find and flag non-qualified references to an
instance field. This check can be enabled from Java > Compiler
> Style preference page (off by default).
This option supports a coding style where all references to instance fields are qualified in order to make them visibly distinct from references to local variables. |
Java compiler option for flagging finally block which cannot complete normally | The Java compiler can now find and flag finally blocks which cannot complete normally (as defined in the Java Language Specification). Finally blocks which cannot complete normally can be confusing and are considered bad practice. This check can be enabled from Java > Compiler > Style preference page (Warn by default). |
Empty control flow statement | The Java compiler can now flag an empty statement used as the body of a control flow statement. See preference under Java > Compiler > Style > Empty statement |
Java compiler option for flagging undocumented empty blocks | The Java compiler can now find and flag empty blocks which are not documented with a comment. Totally empty method and type bodies are also suspicious. This check can be enabled from Java > Compiler > Style preference page (off by default). |
Find variables that hide another field or variable | The Java compiler can now find local variable declarations and fields
which hides another field or variable. The option to turn this checking
on is found on the Java > Compiler >Advanced preference
page (by default they are not reported):
|
Find unnecessary type checks in Java code | The Java compiler can now find and flag unnecessary casts or 'instanceof' operations. The option to turn these checks on is found on the Java > Compiler > Unused Code preference page (by default they are not reported). |
Java compiler option for flagging unnecessary checked exceptions | The Java compiler can now find and flag unnecessary checked exceptions
that
are declared but not thrown. This check can be enabled from Java >
Compiler > Unused Code preference page (off by default).
Note that a given method can always declare to throw fewer checked exceptions than declared in the superclass (or interface). |
Quick Fixes for the new compiler options | The new Java compiler options come with the corresponding Quick Fixes:
Unnecessary declaration of thrown exception: |
Javadoc comment handling | The Eclipse Java compiler now processes Javadoc comments. Search
reports references in doc comments, and refactoring updates these
references as well. This feature is controlled from the Java >
Compiler > Javadoc preference tab (or set for an individual
project using Project > Properties > Java Compiler > Javadoc).
When turned on, malformed Javadoc comments are marked in the Java
editor: |
Quick fixes for problems in Javadoc comments | After enabling the new problem markers in Javadoc comments (previous item), you can use Quick fix in the Java editor to correct missing Javadoc tags. Simply click on the light bulb or use Edit > Quick Fix (Ctrl+1). |
Inlining JSR bytecode | The Java compiler can now optionally avoid generating class files using the JSR bytecode instruction (typically used in compiling try-finally blocks), instead inlining the instructions for the corresponding subroutine. The generated class files are a bit bigger but generally load faster. This mode is anticipating support for the JSR 202. See preference under Java > Compiler > Compliance and Classfiles. |
Running individual JUnit test requiring special set-up | JUnit now supports decorating an individual test for a test run. This
is done by implementing a public static setUpTest(Test) method in your
TestCase class as shown here: The setUpTest method is automatically used when a test is about to be executed individually (including re-running a failed test). The result returned by setUpTest is run instead of the given test, with the common use being to wrap the given test with special set-up or tear-down. |
Improved string compare in JUnit view | When a JUnit test fails because a string is not as expected, clicking on the magnifier button in the tool bar to view the differences between the strings in a compare viewer: |