/**
	   * The completed token is the first token of a constructor
	   * invocation expression.
	   * e.g.
	   * 
	   * public class X {
	   *   public void bar() {
	   *     new Foo| // completion occurs at |
	   *   }
	   * }
	   */
	

If you still want the above code to compile in compliance < 1.7, to mimic JDK 6 or below, you can use the system property tolerateIllegalAmbiguousVarargsInvocation to force Eclipse to tolerate such ambiguous varargs cases. This property can e.g. be set in the eclipse.ini file after the -vmargs setting:

...
        	 -vmargs
			-DtolerateIllegalAmbiguousVarargsInvocation=true
			...

Note: With this setting, Eclipse also mimics JDK 6 and below in raising an error in other cases that are legal in both JDK 7 and Eclipse:

• invalidJavadoc: set all warnings for malformed Javadoc tags
• invalidJavadocTag: validate Javadoc tag arguments
• invalidJavadocTagDep: validate deprecated references in Javadoc tag args
• invalidJavadocTagNotVisible: validate non-visible references in Javadoc tag args
• invalidJavadocVisibility(<visibility>): specify visibility modifier for malformed Javadoc tag warnings
• missingJavadocTags: enable detection of missing Javadoc tags
• missingJavadocTagsOverriding: detect missing Javadoc tags in overriding methods
• missingJavadocTagsMethod: detect missing Javadoc tags for method type parameter
• missingJavadocTagsVisibility(<visibility>): specify visibility modifier for missing Javadoc tags warnings
• missingJavadocComments: detect missing Javadoc comments
• missingJavadocCommentsOverriding: detect missing Javadoc tags in overriding methods
• missingJavadocCommentsVisibility(<visibility>): specify visibility modifier for missing Javadoc comments warnings
• nullAnnotConflict: detect conflict between null annotation specified and nullness inferred. Is effective only with nullAnnot option enabled
• nullAnnotRedundant: detect redundant specification of null annotation. Is effective only with nullAnnot option enabled
• nullUncheckedConversion: detect unchecked conversion from non-annotated type to @NonNull type. Is effective only with nullAnnot option enabled
• unusedParam: detect unused parameter
• unusedParamOverriding: detect unused parameter for overriding method
• unusedParamImplementing: detect unused parameter for implementing method
• unusedParamIncludeDoc: detect unused parameter documented in comment tag
• unusedThrownWhenOverriding: detect unused declared thrown exception in overriding method
• unusedThrownIncludeDocComment: detect unused declared thrown exception, documented in a comment tag
• unusedThrownExemptExceptionThrowable: detect unused declared thrown exception, exempt Exception and Throwable

For more information on using batch compiler options, please refer to Help > Java Development User Guide > Tasks > Compiling Java Code > Using the batch compiler.

If your code uses Java 1.6 or higher, the @Override annotation is also added to methods that override an interface method. If you don't want to use @Override in this case, then follow the link and disable the corresponding compiler option:

You may also want to enable the diagnostic for Missing '@Override' annotation.

The Unused type parameter diagnostic is set to Ignore by default and can be enabled on the Java > Compiler > Errors/Warnings preference page.

For the sake of code readability, JDT expects null annotations of an overridden method to be repeated in overriding methods. In the following example the analysis normally complains that arg is not annotated in ClientClass, which means, this class doesn't formally conform to the contract of its super-interface:

Starting with 4.3M4 this behavior can be changed by selecting the option Inherit null annotations:

In this new mode the analysis implicitly fills in all missing annotations in overriding methods and uses the annotations from the overridden method. In the above example the error will go away, and analysis concludes that the code is actually safe, which is likely when the contract had already been defined in the javadoc comment and the implementor actually adheres to that contract. If, on the other hand, the implementation does not comply with the inherited specification, new errors will be reported as shown below:

If inheritance of null annotations encounters any ambiguity or conflict the analysis falls back to requiring explicit annotations.

• If the field is not properly initialized to a non-null value.
• If a value is assigned to the field that is not known to be non-null.

In return to these obligations, dereferencing a @NonNull field is regarded as always safe.

If a field is marked as @Nullable, generally every direct dereference of the field is flagged as a potential null pointer access. Even a null check for such a field is not a perfect protection due to dangers of side effects, effects via aliased references, and concurrency.

As a compromise between safety and convenience, the compiler can be configured to apply "syntactic null analysis for fields". With this option enabled, the compiler syntactically recognizes a narrow range of code patterns where a null-check of a field is directly followed by a dereference or an assignment to a @NonNull variable. For these particular situations, no problem will be reported.

In the following example, the check in line 12 properly protects the access in line 13, whereas the knowledge that field nullable holds a non-null value (in line 15) is spoiled by the intermediate statement in line 16:

This is the option that enables the syntactic analysis (under the heading Java Compiler > Errors/Warnings):

Generally, this analysis looks for close() method calls directly on a resource (any value of type Closeable). However, in order to reduce boilerplate exception handling, several libraries are providing methods like closeQuietly(Closeable). Previously, the analysis would complain about the missing call to close() as shown below:

This warning is not relevant and will no longer be reported. To achieve this, JDT now hardcodes a (short) white list of functions that are known to safely close a given resource.

The suggested package name is the name of the project if the source folder does not contain any package and if the project name is a valid package name. In case of type creation wizards, if the source folder contains exactly one package then the name of that package is used as the suggested package name.

Extenders must provide an implementation of org.eclipse.jdt.launching.ILibraryLocationResolver which can provide package roots, source paths, Javadoc locations and index locations for a library.

The new preference can be found on the Java > Debug preference page.

At the same time, our good old friend org.junit_3.8.2 has been retired, and the org.junit4 compatibility bundle has also been removed. Your Require-Bundle: entries should just point to org.junit;bundle-version="4.11.0" (or an earlier version, if you like).

Note that JUnit 4 still contains the JUnit 3 APIs. If you need org.junit_3.8.2 back for whatever reason, you can still get it from Orbit.