Add @Nullable annotations and NullAway profile for Maven 4 API#11818
Add @Nullable annotations and NullAway profile for Maven 4 API#11818gnodet wants to merge 1 commit into
Conversation
ffcc698 to
b603fc4
Compare
…ile-time null checks - Add opt-in NullAway profile (-Pnullaway) using Error Prone 2.36.0 + NullAway 0.12.6 for compile-time null safety checking on org.apache.maven.api packages - Add @nullable annotations to fields, method parameters, and return types across the Maven 4 API where values can genuinely be null - Add @nullable to Velocity model template (model.vm) for generated model classes: non-primitive, non-collection fields and their getters - Add @nullable to hand-written template files: InputLocation, InputSource, InputLocationTracker, ImmutableCollections - Add @nullable to XmlNode builder, XmlService merge methods, XmlReaderRequest, XmlWriterRequest - Add @nullable to builder fields in request classes (fields start null before builder methods are called) - Add requireNonNull() validation in builder build() methods for parameters that must be non-null, preserving existing @nonnull API contracts - Fix InputLocation.locations field: not nullable (always initialized via ImmutableCollections which returns empty map for null input) - Fix Sources.BuildPathSource.resolve() null safety for Path.getParent() - Add @nullable to Nullable annotation itself (meta-annotation for NullAway) - Fix Phase.getEffectiveId() return annotation in lifecycle.mdo Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
b603fc4 to
7a89764
Compare
gnodet
left a comment
There was a problem hiding this comment.
Review: Add @nullable annotations and NullAway profile for Maven 4 API
Well-structured PR that adds @Nullable annotations and an opt-in NullAway Error Prone profile across the Maven 4 API. The annotations are overwhelmingly correct, CI passes across all platforms and JDK versions, and the NullAway profile is properly configured as opt-in at WARN level — the right approach for incremental adoption.
Key strengths
@Nullableannotations are applied consistently to builder fields (which start null before builder methods are called) and to genuinely nullable API return valuesrequireNonNull()additions in builderbuild()methods correctly enforce the distinction between nullable builder state and non-null API contracts- The
InputLocation.locationsfix andXmlNodevalue null-safety fix intoStringObject()are genuine bug fixes - Session parameter annotations match the underlying factory request contracts
Finding: ModelBuilderRequest.getSource() contract change (medium)
api/maven-api-core/src/main/java/org/apache/maven/api/services/ModelBuilderRequest.java
getSource() changed from @Nonnull to @Nullable. Multiple callers in DefaultModelBuilder dereference getSource() without null checks — e.g., request.getSource().getPath(), request.getSource().resolve(...). The build() method does not add requireNonNull for source (unlike session and requestType).
If source is genuinely nullable, the callers need null guards. If it was @Nonnull for a reason, consider either:
- Adding
requireNonNull(source, "source cannot be null")inbuild()to preserve the non-null contract, or - Adding null guards in
DefaultModelBuildercallers
Observation: getRepositoryMerging() contract change (low)
Same pattern — getRepositoryMerging() changed from @Nonnull to @Nullable. The builder field starts null and build() does not enforce non-null. Callers should be audited for null-safety, though this is less likely to cause issues than getSource().
This review was generated by an AI agent and may contain inaccuracies. Please verify all suggestions before applying.
Claude Code on behalf of Guillaume Nodet
Reviewed 3 PRs: apache#12416 (BOM version resolution fix), apache#12410 (path-traversal re-review), apache#11818 (@nullable annotations). 5 findings verified, 5 false positives dropped. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Summary
-Pnullaway) using Error Prone 2.36.0 + NullAway 0.12.6 for compile-time null safety checking onorg.apache.maven.apipackages@Nullableannotations across the Maven 4 API where values can genuinely be null: fields, method parameters, return types, builder fields, generated model code (via Velocity template)requireNonNull()validation in builderbuild()methods to preserve existing@NonnullAPI contracts — no@Nonnullannotations were changed to@NullableInputLocation.locationsfield: was incorrectly annotated@Nullablebut is never null (always initialized viaImmutableCollectionswhich returns empty map for null input)Sources.BuildPathSource.resolve()null safety forPath.getParent()which can return nullDetails
The NullAway profile runs at
WARNlevel with-XepDisableAllChecksso only NullAway warnings are reported. It is designed as an opt-in quality check, not a build gate. The profile configures NullAway to recognize Maven's custom@Nullableand@Nonnullannotations.Files changed fall into these categories:
@Nullableto genuinely nullable fields, params, and return types@Nullableto builder fields (which start null) andrequireNonNull()inbuild()methods for non-null paramsmodel.vm): Added@Nullableto non-primitive, non-collection generated fields and their gettersInputLocation.java,InputSource.java, etc.): Added@Nullableannotations.mdomodel files: Added@Nullableto code segments where neededTest plan
mvn clean test -f api)mvn clean compile -f api)mvn clean compile -f api -Pnullaway)🤖 Generated with Claude Code