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 4 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)
|
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