Java Compile Errors/Warnings Preferences

Non-static access to a static member

When enabled, the compiler will issue an error or a warning whenever a static field or method is accessed with an expression receiver. A reference to a static member should be qualified with a type name.

Warning

Indirect access to a static member

When enabled, the compiler will issue an error or a warning whenever a static field or method is indirectly accessed. A static field of an interface should be qualified with the declaring type name.

Ignore

Unqualified access to instance field

When enabled, the compiler will issue an error or a warning whenever it encounters a field access which is not qualified (e.g. misses a 'this').

Ignore

Access to a non-accessible member of an enclosing type

When enabled, the compiler will issue an error or a warning whenever it emulates access to a non-accessible member of an enclosing type. Such accesses can have performance implications.

Ignore

Parameter assignment

Assigning a value to a parameter is generally considered poor style programming. When this option is enabled, the compiler will signal such scenario either as an error or a warning.

Ignore

Non-externalized strings

When enabled, the compiler will issue an error or a warning for non externalized String literal (i.e. non tagged with //$NON-NLS-<n>$) or for non externalized String tags which do not belong to a String.

Ignore

Undocumented empty block

When enabled, the compiler will issue an error or a warning whenever it encounters an empty block statement with no explaining comment.

Ignore

Resource not managed via try-with-resource (1.7 or higher)

When enabled, the compiler will issue an error or a warning if a local variable holds a value of type 'java.lang.AutoCloseable', and if the method 'close()' is explicitly invoked on that resource, but the resource is not managed by a try-with-resources block.

Ignore

Method with a constructor name

Naming a method with a constructor name is generally considered poor style programming. When this option is enabled, the compiler will signal such scenario either as an error or a warning.

Warning

Method can be static

When enabled, the compiler will issue an error or a warning for methods which are private or final and which refer only to static members.

Ignore

Method can potentially be static

When enabled, the compiler will issue an error or a warning for methods which are not private or final and which refer only to static members. Note that methods can be overridden in a subclass, so if you make a "potentially static" method static, this may break existing clients.

Ignore

Comparing identical values ('x == x')

When enabled, the compiler will issue an error or a warning if a comparison is involving identical operands (e.g 'x == x').

Warning

Assignment has no effect (e.g. 'x = x')

When enabled, the compiler will issue an error or a warning whenever an assignment has no effect (e.g. 'x = x').

Warning

Possible accidental boolean assignment (e.g. 'if (a = b)')

When enabled, the compiler will issue an error or a warning whenever it encounters a possible accidental boolean assignment (e.g. 'if (a = b)').

Ignore

Boxing and unboxing conversions

When enabled, the compiler will issue an error or a warning whenever it encounters a boxing or unboxing conversion. Autoboxing may affects performance negatively.

Ignore

Using a char array in string concatenation

When enabled, the compiler will issue an error or a warning whenever a char[] expression is used in String concatenations,

Warning

Inexact type match for vararg arguments

When enabled, the compiler will issue an error or a warning whenever it encounters an inexact type match for vararg arguments.

Warning

Unlikely argument type for collection methods using 'Object'

When enabled, the compiler will issue an error or warning when certain well-known Collection methods that take an 'Object', e.g. 'Map#get(Object)', are used with an argument type, that seems to be not related to the corresponding type argument of the Collection.

Warning

Perform strict analysis against the expected type

By default, this analysis will apply some heuristics to determine whether two types may be related, which can be changed via this option. When enabled, the heuristics will be replaced with strict compatibility checks, i.e., each argument that is not strictly compatible with the expected type will trigger an error or warning.

Off

Unlikely argument type for method equals()

When enabled, the compiler will issue an error or warning when 'java.lang.Object#equals(Object)' is used with an argument type, that seems to be not related to the receiver's type, or correspondingly when the arguments of 'java.util.Objects#equals(Object, Object)' have types that seem to be not related to each other.

Info

Empty statement

When enabled, the compiler will issue an error or a warning whenever it encounters an empty statement (e.g. a superfluous semicolon).

Ignore

Unused object allocation

When enabled, the compiler will issue an error or a warning when it encounters an allocated object which is not used, e.g.

Ignore

Incomplete 'switch' cases on enum

When enabled, the compiler will issue an error or a warning whenever it encounters a 'switch' statement which does not contain a 'default' case nor case statements for every enum constant of the referenced enum.

This warning is recommended by the Java Language Specification 14.11. It helps to ensure that 'switch' statements cover all possible enum values.

Warning

Signal even if 'default' case exists

When enabled, the compiler additionally will issue an error or a warning if an enum constant is not covered by a case, even if a 'default' case exists.

This option helps to catch missing case statements when a new enum constant is added.

Off

'switch' is missing 'default' case

When enabled, the compiler will issue an error or a warning if a 'switch' statement lacks a 'default' case. Consequently, a missing 'default' will be flagged even if all possible values are otherwise covered by 'case' statements.

This option helps to ensure that new 'switch' expression values are handled explicitly, rather than being skipped. It can also help to explain compile errors for un-initialized variables after a 'switch' statement: The set of legal values can grow in the future, so the variable also needs to be initialized in the 'default' case.

Ignore

'switch' case fall-through

When enabled, the compiler will issue an error or a warning when a case may be entered by falling through a preceding, non empty case.

Ignore

Hidden catch block

Locally to a try statement, some catch blocks may hide others , e.g.

When enabled, the compiler will issue an error or a warning for hidden catch blocks corresponding to checked exceptions.

Warning

'finally' does not complete normally

When enabled, the compiler will issue an error or a warning whenever a 'finally' statement does not complete normally (e.g. contains a return statement).

Warning

Dead code (e.g. 'if (false)')

When enabled, the compiler will issue an error or a warning when it encounters dead code (e.g 'if (false)' ).

Warning

Resource leak

When enabled, the compiler will issue an error or a warning if a local variable holds a value of type 'java.lang.AutoCloseable' (compliance >= 1.7) or a value of type 'java.io.Closeable' (compliance <= 1.6) and if flow analysis shows that the method 'close()' is not invoked locally on that value.

Warning

Potential resource leak

When enabled, the compiler will issue an error or a warning if a local variable holds a value of type 'java.lang.AutoCloseable' (compliance >= 1.7) or a value of type 'java.io.Closeable' (compliance <= 1.6) and if flow analysis shows that the method 'close()' is not invoked locally on that value for all execution paths.

Ignore

Serializable class without serialVersionUID

When enabled, the compiler will issue an error or a warning whenever a type implementing 'java.io.Serializable' does not contain a serialVersionUID field.

Warning

Missing synchronized modifier on inherited method

When enabled, the compiler will issue an error or a warning when it encounters an inherited method which is missing the synchronized modifier.

Ignore

Class overrides 'equals()' but not 'hashCode()'

When enabled, the compiler will issue an error or a warning when it encounters a class which overrides 'equals()' but not 'hashCode()'.

Ignore

Field declaration hides another field or variable

When enabled, the compiler will issue an error or a warning if a field declaration hides another inherited field.

Ignore

Local variable declaration hides another field or variable

When enabled, the compiler will issue an error or a warning if a local variable declaration hides another field or variable.

Ignore

Include constructor or setter method parameters

When enabled, the compiler additionally will issue an error or a warning if a constructor or setter method parameter hides another field or variable.

Off

Type parameter hides another type

When enabled, the compiler will issue an error or a warning if i.e. a type parameter of an inner class hides an outer type.

Warning

Method does not override package visible method

A package default method is not visible in a different package, and thus cannot be overridden. When this option is enabled, the compiler will signal such scenario either as an error or a warning.

Warning

Interface method conflicts with protected 'Object' method

When enabled, the compiler will issue an error or a warning whenever an interface defines a method incompatible with a non-inherited Object method. Until this conflict is resolved, such an interface cannot be implemented, e.g.

Warning

Deprecated API

When enabled, the compiler will signal use of deprecated API either as an error or a warning.

Warning

Signal use of deprecated API inside deprecated code

When enabled, the compiler will signal use of deprecated API inside deprecated code. The severity of the problem is controlled with option "Deprecated API".

Off

Signal overriding or implementing deprecated method

When enabled, the compiler will signal overriding or implementing a deprecated method The severity of the problem is controlled with option "Deprecated API".

Off

Forbidden reference (access rules)

When enabled, the compiler will signal a forbidden reference specified in the access rules.

Error

Discouraged reference (access rules)

When enabled, the compiler will signal a discouraged reference specified in the access rules.

Warning

Value of local variable is not used

When enabled, the compiler will issue an error or a warning whenever a local variable is declared but its value is never used within its scope.

Warning

Value of method parameter is not used

When enabled, the compiler will issue an error or a warning whenever a method parameter is declared but its value is never used within its scope.

Ignore

Ignore in overriding and implementing methods

When enabled, the compiler will not issue an error or a warning whenever a parameter is declared but never used within its scope in a method that overrides or implements another method.

On

Unused type parameter

When enabled, the compiler will issue an error or a warning for unused type parameter.

Ignore

Ignore parameters documented with '@param' tag

When enabled, the compiler will not issue an error or a warning whenever an unread parameter is documented with an '@param' tag.

On

Value of exception parameter is not used

When enabled, the compiler will issue an error or a warning when a catch clause of a try statement has an exception parameter that is not used in its body.

Ignore

Unused import

When enabled, the compiler will issue an error or a warning for unused import reference.

Warning

Unused private member

When enabled, the compiler will issue an error or a warning whenever a private member is declared but never used within the same unit.

Warning

Unnecessary 'else' statement

When enabled, the compiler will issue an error or a warning whenever it encounters an unnecessary else statement (e.g. if (condition) return; else doSomething();).

Ignore

Unnecessary cast or 'instanceof' operation

When enabled, the compiler will issue an error or a warning whenever it encounters an unnecessary cast or 'instanceof' operation (e.g. if (object instanceof Object) return;).

Ignore

Unnecessary declaration of thrown exception

When enabled, the compiler will issue an error or a warning whenever it encounters an unnecessary declaration of a thrown exception.

Ignore

Ignore in overriding and implementing methods

When enabled, the compiler will not issue an error or a warning whenever it encounters an unnecessary declaration of a thrown exception in a method that overrides or implements another method.

On

Ignore exceptions documented with '@throws' or '@exception' tags

When enabled, the compiler will not issue an error or a warning whenever an unnecessary declaration of a thrown exception is documented with an '@throws' or '@exception' tag.

On

Ignore 'Exception' and 'Throwable'

When enabled, the compiler will not issue an error or a warning whenever it encounters an unnecessary declaration of 'Exception' and 'Throwable' exception

On

Unused 'break' or 'continue' label

When enabled, the compiler will issue an error or a warning whenever it encounters an unused 'break' or 'continue' label.

Warning

Redundant super interface

When enabled, the compiler will issue an error or a warning whenever it encounters a type which explicitly implements an interface that is already implemented by any of its supertypes.

Ignore

Unchecked generic type operation

When enabled, the compiler will issue an error or a warning whenever it encounters an unchecked generic type operation.

Warning

Usage of a raw type

When enabled, the compiler will issue an error or a warning whenever it encounters a usage of a raw type (e.g. List instead of List<String>).

Warning

Generic type parameter declared with a final type bound

When enabled, the compiler will issue an error or a warning whenever it encounters a type bound involving a final type.

Warning

Redundant Type Arguments (1.7 or higher)

When enabled, the compiler will issue an error or a warning whenever it encounters an unnecessary type argument in allocation expression. Use a diamond operator instead - applicable for levels 1.7 and above.

Ignore

Ignore unavoidable generic type problems due to raw APIs

When enabled, the compiler will ignore generics-related type problems that could not have been avoided by the programmer, because a referenced API already contains raw types. As an example, a type may be forced to use raw types in its method signatures and return types because the methods it overrides from a super type are declared to use raw types in the first place.

When the old API is eventually generified, then most of these problems either go away, or you will see a compile error because the type arguments you used are not correct. For raw references in method signatures, the raw type problem will reappear.

Off

Missing '@Override' annotation

When enabled, the compiler will issue an error or a warning whenever it encounters a method overriding another implemented method, and the '@Override' annotation is missing.

Ignore

Include implementations of interface methods (1.6 or higher)

When enabled, the compiler will also issue an error or a warning whenever it encounters a method overriding or implementing a method declared in an interface, and the '@Override' annotation is missing.
Note that '@Override' is only allowed on such methods if the compiler compliance level is 1.6 or higher, so this error or warning will never appear in 1.5 code.

On

Missing '@Deprecated' annotation

When enabled, the compiler will issue an error or a warning whenever it encounters a type that has a javadoc '@deprecated' tag, but does not have a corresponding Java '@Deprecated' annotation.

Ignore

Annotation is used as super interface

When enabled, the compiler will issue an error or a warning whenever it encounters a type implementing an annotation. Although possible, this is considered bad practice.

Warning

Unhandled token in '@SuppressWarnings'

When enabled, the compiler will issue an error or a warning whenever it encounters an unknown token in a '@SuppressWarnings' annotation.

Warning

Enable '@SuppressWarnings' annotations

When enabled, the compiler will process '@SuppressWarnings' annotations. When disabled, it will act as if all '@SuppressWarnings' annotations were removed.

See also Excluding warnings using @SuppressWarnings.

On

Unused '@SuppressWarnings' token

When enabled, the compiler will issue an error or a warning whenever it encounters an unused token in a '@SuppressWarnings' annotation.

Warning

Suppress optional errors with '@SuppressWarnings'

When enabled, the '@SuppressWarnings' annotation will also suppress optional compile errors, i.e. options set to "Error" here. Mandatory compile errors cannot be suppressed.

Off

Null pointer access

When enabled, the compiler will issue an error or a warning when it encounters that a local variable which is certainly null is dereferenced. Note that the analysis can not find all null pointer accesses, see Potential null pointer access.

Warning

Potential null pointer access

When enabled, the compiler will issue an error or a warning when it encounters that a local variable which may be null is dereferenced. Note that the analysis is fairly conservative, it only considers cases where there is something suspicious.

The quality of the analysis can be improved by using null-annotations, which can be enabled using the option Enable annotation-based null analysis

Ignore

Redundant null check

When enabled, the compiler will issue an error or a warning whenever a local variable which can not be null is tested for null.

Ignore

Include 'assert' in null analysis

When enabled, the compiler will honor 'assert' statement when doing the null analysis.

Off

Enable annotation-based null analysis

When enabled, the compiler will interpret annotations @Nullable, @NonNull, and @NonNullByDefault as specifying whether or not a given type includes the value 'null'.

The effect of these analyses is further controlled by the following sub-options.

See also Using null annotations.

Off

Violation of null specification

Depending on this option, the compiler will issue either an error or a warning whenever one of the following situations is detected:

1. A method declared with a nonnull annotation returns a nullable expression.
2. A nullable expression is passed as an argument in a method call where the corresponding parameter of the called method is declared with a nonnull annotation.
3. A nullable expression is assigned to a local variable that is declared with a nonnull annotation.
4. A method that overrides an inherited method declared with a nonnull annotation tries to relax that contract by specifying a nullable annotation (prohibition of contravariant return).
5. A method that overrides an inherited method which has a nullable declaration for at least one of its parameters, tries to tighten that null contract by specifying a nonnull annotation for its corresponding parameter (prohibition of covariant parameters).

In the above an expression is considered as nullable if either it is statically known to evaluate to the value null, or if it is declared with a nullable annotation.

Error

Conflict between null annotations and null inference

Depending on this option, the compiler will issue either an error or a warning whenever one of the following situations is detected:

1. A method declared with a nonnull annotation returns an expression that is statically known to evaluate to a null value on some flow.
2. An expression that is statically known to evaluate to a null value on some flow is passed as an argument in a method call where the corresponding parameter of the called method is declared with a nonnull annotation.
3. An expression that is statically known to evaluate to a null value on some flow is assigned to a local variable that is declared with a nonnull annotation.

Error

Unchecked conversion from non-annotated type to @NonNull type

Depending on this option, the compiler will issue either an error or a warning whenever one of the following situations is detected:

1. A method declared with a nonnull annotation returns an expression for which insufficient nullness information is available for statically proving that no flow will pass a null value at runtime.
2. An expression for which insufficient nullness information is available for statically proving that it will never evaluate to a null value at runtime is passed as an argument in a method call where the corresponding parameter of the called method is declared with a nonnull annotation.
3. An expression for which insufficient nullness information is available for statically proving that it will never evaluate to a null value at runtime is assigned to a local variable that is declared with a nonnull annotation.

Unchecked conversion is usually a consequence of using other unannotated variables or methods.

Warning

Problems detected by pessimistic analysis for free type variables

Unless set to "Ignore", type variables not affected by any explicit null annotation are pessimistically analysed in two directions: When reading a value of this type, it is assumed to be nullable. When this type appears as the required type (i.e., at the left hand side of an assignment or variable initialization, or as the method return type against which a return statement is being checked) the type is considered to require the nonnull property.

Problems reported due to this pessimistic analysis are reported with the level given in this option.

This option is only relevant when using null type annotations.

Warning

Unsafe '@Nonnull' interpretation of free type variable from library

When enabled, the compiler will issue an error or a warning against a method call if all of the following hold:

• The method's declared return type is a type variable without any null annotation.
• For the given invocation this type variable is substituted with a nonnull type.
• The type declaring the method is provided by a third-party library.
• No null annotations exist for this library type, neither in its class file nor using external annotations.

This particular situation leverages the option to consistently substitute all occurrences of a type variable with a nonnull type, but it bears the risk that the library type may not be aware of null annotations thus lacking a necessary @Nullable annotation for a particular occurrence of a type variable.

Warning

Redundant null annotation

When enabled, the compiler will issue an error or a warning when a non-null annotation is applied although the same effect is already achieved by a default applicable at the current location. Such a default may be set by using the @NonNullByDefault annotation.

Warning

'@NonNull' parameter not annotated in overriding method

When enabled, the compiler will issue an error or a warning against a parameter of a method that overrides an inherited method if all of the following hold:

• The overridden method declares the corresponding parameter as non-null.
• The parameter in the overriding method has no null annotation.
• The overriding method is not affected by a nullness default.
• Inheritance of null annotations is disabled.

Warning

Missing '@NonNullByDefault' annotation on package

When enabled, the compiler will issue an error or a warning in the following cases:

1. When a package does not contain a default nullness annotation, as a result of missing package-info.java or missing default nullness annotation in package-info.java.
2. When a type inside a default package does not contain a default nullness annotation.

Ignore

Use default annotations for null specifications

When enabled, the compiler will use the default set of annotations for null specifications. These annotations are included in the Eclipse SDK in the org.eclipse.jdt.annotation bundle.

You can specify different annotation names to use in your projects, but be aware that the Eclipse compiler only supports the semantics specified in the default annotations:

• org.eclipse.jdt.annotation.Nullable: A fully qualified name of a Java annotation type, which when applied to a type in a method signature, variable declaration or field declaration, will be interpreted as a specification that null is a legal value in that position.
  Currently supported positions are: method parameters, method return type, local variables and fields.
• org.eclipse.jdt.annotation.NonNull: A fully qualified name of a Java annotation type, which when applied to a type in a method signature, variable declaration or field declaration, will be interpreted as a specification that null is not a legal value in that position.
  Currently supported positions are: method parameters, method return type, local variables and fields.
• org.eclipse.jdt.annotation.NonNullByDefault: A fully qualified name of a Java annotation type. When applied to an element without an annotation argument, all unannotated types in method signatures and field declarations within the annotated element will be treated as if they were specified with the non-null annotation.
  Only when using the default annotation type org.eclipse.jdt.annotation.NonNullByDefault, also the opposite effect is supported: When the annotation is applied with the constant 'false' as its argument (or '{}' in the case of type annotations), all corresponding defaults at outer scopes will be canceled for the annotated element.

The compiler supports exactly one primary set of annotation types for null specification. Additionally, an arbitrary number of secondary annotation types can be configured to carry the same semantics. Secondary annotation types are supported for the sole purpose of interfacing with 3rd party code that is already specified using other null annotations than the primary annotations types of the current project.

On

Inherit null annotations

When enabled, the compiler will check for each method without any explicit null annotations: If it overrides a method which has null annotations, it will treat the current method as if it had the same annotations as the overridden method.

Annotation inheritance will use the effective nullness of the overridden method after transitively applying inheritance and after applying any default nullness at the site of the overridden method.

If different implicit null annotations (from a nonnull default and/or overridden methods) are applicable to the same type in a method signature, this is flagged as an error and an explicit null annotation must be used to disambiguate.

Off

Enable syntactic null analysis for fields

When enabled, the compiler will detect certain syntactic constellations where a null related warning against a field reference would normally be raised but can be suppressed at low risk given that the same field reference was known to be non-null immediately before. When using this option please see these hints.

Off

Search for external annotations in all build path locations

When enabled, the compiler will search all build path locations for external annotations to be considered during annotation-based null analysis. This strategy will be applied to every class file found during compilation.
The default is to search only those locations that are specified using the "external annotations" property of each individual build path entry and apply any annotations found only to classes in that corresponding build path entry.

Off