CAMEL-22640: Add JSpecify null safety annotations to camel-api#22313
CAMEL-22640: Add JSpecify null safety annotations to camel-api#22313gnodet wants to merge 6 commits intoapache:mainfrom
Conversation
Add @NullMarked (JSpecify 1.0.0) to all packages in camel-api, making non-null the default. Annotate ~200 API interfaces and classes with @nullable where parameters or return values can legitimately be null, covering the core API surface including CamelContext, Exchange, Message, Component, Endpoint, TypeConverter, and all SPI interfaces. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
|
🌟 Thank you for your contribution to the Apache Camel project! 🌟 🐫 Apache Camel Committers, please review the following items:
|
Scan actual implementations (not just Javadoc) for return null, null field values, and caller null-checks. Adds missing @nullable annotations and moves @NullMarked to package-level only. Key additions found by implementation scanning: - Exchange.getPattern() can be null (field uninitialized) - Message.getExchange() can be null (field starts null) - Route.getOnException/navigate() can return null - DelegateProcessor.getProcessor() can be null (LazyStartProducer) - Various transient exception fields nullable after deserialization - ConsumerTemplate.receiveBody() without timeout can return null - CamelContext.getComponent() overloads can return null - ExtendedCamelContext.getErrorHandlerFactory() can be null - Multiple SPI methods found nullable through impl analysis Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
- CamelExchangeException: accept @nullable exchange (field already nullable) - CamelExecutionException: accept @nullable exchange (called with null from ExchangeHelper) - ExchangeTimedOutException: accept @nullable exchange (consistent with parent) - Transformer: setFrom/setTo accept @nullable (fields already nullable, called with null from reifiers) Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
|
This is interresting and when more and more open source projects adopt this. Wonder what the situation is at Quarkus ? |
…null-annotations # Conflicts: # core/camel-api/src/main/java/org/apache/camel/spi/Transformer.java # core/camel-api/src/main/java/org/apache/camel/vault/AwsVaultConfiguration.java # core/camel-api/src/main/java/org/apache/camel/vault/AzureVaultConfiguration.java # core/camel-api/src/main/java/org/apache/camel/vault/CyberArkVaultConfiguration.java # core/camel-api/src/main/java/org/apache/camel/vault/GcpVaultConfiguration.java # core/camel-api/src/main/java/org/apache/camel/vault/HashicorpVaultConfiguration.java # core/camel-api/src/main/java/org/apache/camel/vault/IBMSecretsManagerVaultConfiguration.java # core/camel-api/src/main/java/org/apache/camel/vault/SpringCloudConfigConfiguration.java # parent/pom.xml
|
Yes, Quarkus is moving towards JSpecify as well. Their official account promoted it, and there's a detailed guide on using It's not baked into the Quarkus framework itself yet (unlike Spring Framework 7 which switched its entire codebase to JSpecify), but the ecosystem is actively adopting it and Quarkus is encouraging its use. Claude Code on behalf of Guillaume Nodet |
|
🧪 CI tested the following changed modules:
Build reactor — dependencies compiled but only changed modules were tested (2 modules)
|
|
I think it would be good to have this in camel-api, which is then the official API for end users of Camel and this would allow better coding experience for users where IDE tools understand this (especially when spring has this included now). And on top of that LLMs can better understand the Camel API as well when its been annotated with this as well. Then we do NOT really have to add these annotations anywhere else in the code base. |
|
@gnodet can you update this PR |
…null-annotations # Conflicts: # core/camel-api/src/main/java/org/apache/camel/NamedNode.java # core/camel-api/src/main/java/org/apache/camel/spi/ModelDumpLine.java
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
gnodet
force-pushed
the
CAMEL-22640-jspecify-null-annotations
branch
from
f332cc5 to
343e9b8
Compare
|
Claude Code on behalf of Guillaume Nodet Closing in favor of #23021 which supersedes this PR. |
2 participants
Summary
Add JSpecify null safety annotations (
@NullMarked/@Nullable) to thecamel-apimodule, aligning with Spring Framework 7 / Spring Boot 4's adoption of JSpecify as the standard null safety annotation library.Changes
org.jspecify:jspecify:1.0.0toparent/pom.xml(dependencyManagement) andcore/camel-api/pom.xml@NullMarkedon all packages: Addedpackage-info.javawith@NullMarkedto all 16 packages in camel-api, making non-null the default@Nullableannotations: Comprehensive audit of all ~200+ Java files, marking parameters, return types, and fields that can be null. Annotations were verified by:return null!= null/== nullguardsObjects.requireNonNull()checks on non-null reference parameters in all concrete classes, providing fail-fast behavior at API boundaries@Nullable— these were fixed:CamelExchangeExceptionconstructors:exchangeparam made@Nullable(field already nullable)CamelExecutionException:exchangeparam made@Nullable(called with null fromExchangeHelper)ExchangeTimedOutException:exchangeparam made@Nullable(consistent with parent)RuntimeExchangeException:exchangeparam already@Nullable(verified)ValidationException:exchangeparam already@Nullable(verified)ResolveEndpointFailedException:uriparam made@NullableExpressionEvaluationException:expression/exchangeparams made@NullableTransformer.setName():scheme/nameparams made@NullableTransformer.setFrom()/setTo(): params made@Nullable(fields already nullable)JsseParameters.parsePropertyValue():valueparam made@NullableEventClock.add()/ContextClock.add():clockparam made@NullableApproach
@NullMarkedduring review, then moved to package-level at the endObjects.requireNonNull()enforcement on concrete classes caught 10+ missed@NullableannotationsJIRA: CAMEL-22640