|
|
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: |
|