gnodet commented on PR #23021: URL: https://github.com/apache/camel/pull/23021#issuecomment-4437368716
Thanks for the thorough review. The intent of this PR is to document **current reality** (what can actually be null today), not **intentionality** (what should ideally be non-null). A few responses: - **BulkTypeConverters `value`**: `CoreTypeConverterRegistry.doConvertTo()` and `fastConvertTo()` both explicitly handle `null` values (returning `null`, or converting to primitive defaults). There's also `ConverterTest.testNullConverter()` confirming this. The `@Nullable` reflects reality. - **ComponentCustomizer/DataFormatCustomizer `condition`**: The field is an optional builder parameter — `condition()` handles `null` by providing a default predicate. The `@Nullable` matches existing behavior. - **LifecycleStrategy thread pool params**: The existing Javadoc already says "(can be null in special cases)" for `sourceId`, `routeId`, `threadPoolProfileId`. The `@Nullable` just formalizes what the docs state. - **ResumeStrategyConfiguration**: The `Cacheable.@Nullable FillPolicy` syntax looks unusual but is the correct JSpecify placement for type-use annotations on nested types — the `@Nullable` must go directly before the simple class name, not before the outer type. Where we agree some parameters *should* be non-null (like thread pool `id`), that's a separate behavioral change — tightening the contract and adding validation. Happy to do that in follow-up PRs where each case can be reviewed individually. This PR intentionally avoids changing semantics. _Claude Code on behalf of Guillaume Nodet_ -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
