Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Clear out junk files and repair common Windows errorsFree Scan →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Eclipse JDT can check Java code against nullability contracts expressed with annotations such as @NonNull and @Nullable. To enable the analysis, open Window > Preferences > Java > Compiler > Errors/Warnings, expand Null Analysis, and enable Annotation-based null analysis. It is disabled by default in the documented Eclipse settings; exact labels can vary by Eclipse/JDT version.
What annotation-based null analysis checks
JDT uses null annotations as part of Java compiler type and flow checks. It compares how code handles values with the contracts declared on fields, parameters, return values, and other supported type positions. Depending on the configured diagnostics, it can report possible null dereferences, nullness contract violations, redundant checks, conflicts between annotations and inferred flow, and conversions where nullness information is insufficient.
| # | Preview | Product | Price | |
|---|---|---|---|---|
| 1 |
|
Eclipse IDE Pocket Guide: Using the Full-Featured IDE | $7.99 | Buy on Amazon |
| 2 |
|
Eclipse | $25.96 | Buy on Amazon |
| 3 |
|
Eclipse IDE - kurz & gut | $6.53 | Buy on Amazon |
| 4 |
|
Eclipse IDE - kurz & gut | $6.92 | Buy on Amazon |
| 5 |
|
Contributing to the Eclipse IDE Project: Principles, Plug-ins and Gerrit Code Review (vogella... | $24.99 | Buy on Amazon |
It is not a proof that an entire application cannot throw a NullPointerException. The compiler analyzes methods incrementally and does not perform whole-system analysis; annotations on method parameters and return types communicate expectations across method boundaries. The Eclipse JDT null-annotations guide explains this method-by-method model.
How to enable it in Eclipse
- Open Window > Preferences (on macOS, use Eclipse > Settings or Preferences, depending on the release).
- Go to Java > Compiler > Errors/Warnings.
- Expand Null Analysis and enable Annotation-based null analysis.
- Review the null-analysis diagnostic severities and related options on the same preference page. Choose warning or error levels appropriate to your team’s adoption stage.
- Apply the settings and rebuild or save affected files so the compiler can report diagnostics.
The corresponding JDT compiler option is org.eclipse.jdt.core.compiler.annotation.nullanalysis; its documented default is disabled. The option has been available since JDT 3.8. Teams configuring compiler options outside the IDE should use the exact option name and check the documentation for their JDT version: Eclipse JDT JavaCore API.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
#1 Best Overall
What the null annotations mean
@NonNull
@NonNull states that null is not a permitted value at the annotated type position. With analysis enabled, JDT treats dereferencing a value of that type as safe, but reports assigning or passing a definitely null value to a non-null field, local, parameter, or return position as a compile-time problem.
@Nullable
@Nullable says null is allowed. Code receiving that value must account for the possibility before dereferencing it, typically by checking for null or otherwise establishing non-nullness along the current control-flow path.
Rank #2
@NonNullByDefault
@NonNullByDefault reduces repetitive annotations by making otherwise unannotated types non-null within its scope. It can be applied at method, type, or package scope; package defaults are commonly declared in package-info.java. Eclipse’s annotation supports using false to cancel an outer default. Do not assume a third-party annotation with a similar name has the same behavior.
The Eclipse-provided annotation types are in the org.eclipse.jdt.annotation bundle. For the API’s contract details, see JDT’s @NonNull API documentation.
Recommended Free Tools
Rank #3
Where to put annotations: declarations and type uses
Before Java 8, JDT supported null annotations on method parameters and returns, local variables, and fields. Java 8 type-use annotations can attach nullness directly to a use of a type, including generic type arguments and bounds. That matters when only part of a compound type may be null: for example, the nullability of a collection reference is distinct from the nullability of its elements.
In the type-use model described by JDT, @NonNull C is a subtype of the corresponding @Nullable C: a non-null C can be used where a nullable C is expected, but nullable C cannot safely be used where a non-null one is required without an appropriate check. Generic type parameters can constrain arguments as non-null or nullable, or leave the nullness unconstrained when either is valid.
Rank #4
When using annotations from another library, check its @Target metadata. An annotation that can be placed on a declaration may not be permitted on the type-use positions your code needs. JDT also lets you configure fully qualified annotation type names, including secondary names for compatibility with third-party vocabularies; its API documentation describes secondary names as an interoperability mechanism, not names JDT uses in its own proposals. See the JDT compiler options documentation.
Why Eclipse may still warn
A warning is tied to a particular configured diagnostic and to what the compiler can infer on the current path. A nullable value may be safe after a check in one branch, but still unsafe on another path. Loops and conditional assignments can also leave a value potentially null. JDT distinguishes definite nulls, values whose status varies with control flow, and cases where missing annotations leave nullness unknown.
- Possible dereference: a value is nullable or may be null at that point; check it or strengthen the upstream contract if non-nullness is guaranteed.
- Contract violation: code supplies null where a non-null parameter, field, or return is required, or implements a method with an incompatible null contract.
- Redundant check: flow analysis already establishes that a value is non-null or null, making a check unnecessary on that path.
- Unknown or unchecked nullness: an unannotated boundary or conversion does not give JDT enough information to verify the contract.
- Annotation conflict: a declared annotation disagrees with the compiler’s flow-based conclusion or another inherited contract.
For overrides, contracts must remain substitutable: an implementation must not weaken the inherited return guarantee or demand stricter parameter nullness than callers of the parent method are entitled to provide. JDT offers configurable inheritance behavior when an override omits explicit null annotations, so check that setting and applicable defaults before interpreting missing annotations as an intentional contract.
Diagnostic severities and options—including null-annotation inheritance and syntactic null analysis for fields—are configurable under the compiler’s Null Analysis preferences. The Eclipse compiler errors and warnings preferences describe the available controls. Since the Help route is labeled “latest,” confirm labels and defaults against the Eclipse/JDT version used by your project.
Quick Recap
Choosing a nullness policy for a project
| Choice | When it helps | Trade-off |
|---|---|---|
Explicit @NonNull and @Nullable annotations |
When contracts need to be visible at specific API boundaries or a project is adopting null analysis gradually. | More annotations to maintain; unannotated code can leave gaps in the information available to JDT. |
@NonNullByDefault scope |
When non-null is the normal policy and exceptions can be marked nullable. | Readers must understand where defaults begin and where they are cancelled; third-party defaults may not match Eclipse’s behavior. |
| Declaration-style annotations | When maintaining code written for pre-Java 8 annotation positions or using an annotation library limited to declarations. | Less precise for nested types such as generic arguments. |
| Java 8 type-use annotations | When nullness needs to distinguish the outer type from its generic arguments or bounds. | Chosen annotations must support the required type-use targets. |
| Eclipse annotations or configured third-party types | Use Eclipse’s standard vocabulary for direct JDT integration, or configure names when interoperating with code that uses another vocabulary. | Confirm exact annotation names, targets, and semantics; similar names do not guarantee identical behavior. |
| Warnings during adoption, errors for enforced contracts | Warnings can help teams address legacy code incrementally; errors can enforce settled rules in builds. | Severity is configurable, but raising it before contracts and dependencies are understood can make existing gaps disruptive. |
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
