# Java Compile Errors/Warnings Preferences

Indicate your preferences for the Errors/Warnings settings on the Java > Compiler > Errors/Warnings preference page.

### Code style

Option | Description | Default
--- | --- | ---
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

### Potential programming problems

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, `"hello" + new char[]{'w','o','r','l','d'}` | 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. `if (name == null)` `new IllegalArgumentException();` | 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. `try { throw new java.io.CharConversionException();` `} catch (java.io.CharConversionException e) {` `} catch (java.io.IOException e) {}` 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

### Name shadowing and conflicts

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. `interface I {` `int clone();` `}` | Warning

### Deprecated and restricted API

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

### Unnecessary code

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

### Generic types

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

### Annotations

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 analysis

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

When Treat above errors like fatal compile errors is enabled, all generated errors, fatal or configurable, lead to non-executable code. If disabled, then your code can be executed as long as it has no fatal error (syntax error, type error, or any error according to the Java Language Specification).

### Related concepts

Problems View
Quick Fix
Java builder
Excluding warnings using @SuppressWarnings