CAMEL-22640: Tighten @Nullable annotations where non-null is enforced

[gnodet]

CAMEL-22640

Summary

Follow-up to #23021 — removes @Nullable from parameters that are already enforced as non-null or are never null in practice. The previous PR documented current reality; this PR tightens the contract where intentionality is clear.

Changes

• ResolveEndpointFailedException.uri: Remove @Nullable from field, constructors, and getter — zero callers across the entire codebase pass null. Add requireNonNull enforcement.
• LifecycleStrategy.onThreadPoolAdd() id param: Remove @Nullable — BaseExecutorServiceManager.onThreadPoolCreated() always computes a non-null id (with StringHelper.notEmpty() enforcement). The original Javadoc "(can be null in special cases)" was accurate when the method was introduced in CAMEL-3437 (the else branch left id as null when source was not a ProcessorDefinition or String), but the caller was later fixed to always generate an id using a source.getClass().getSimpleName() + hashcode fallback.

Not changed

Exception transient fields (InvalidPayloadException.type, ExpectedBodyTypeException.exchange/expectedBodyType) are kept @Nullable — although constructors enforce non-null via requireNonNull, the transient keyword means these fields will be null after Java serialization/deserialization.

Verification

• mvn install -B -pl core/camel-api -DskipTests -am — BUILD SUCCESS
• mvn install -B -pl core/camel-core -DskipTests — BUILD SUCCESS (downstream compilation)
• mvn formatter:format impsort:sort -B -pl core/camel-api — no formatting changes

[github-actions]

🌟 Thank you for your contribution to the Apache Camel project! 🌟
🤖 CI automation will test this PR automatically.

🐫 Apache Camel Committers, please review the following items:

• First-time contributors require MANUAL approval for the GitHub Actions to run
• You can use the command /component-test (camel-)component-name1 (camel-)component-name2.. to request a test from the test bot although they are normally detected and executed by CI.
• You can label PRs using skip-tests and test-dependents to fine-tune the checks executed by this PR.
• Build and test logs are available in the summary page. Only Apache Camel committers have access to the summary.

⚠️ Be careful when sharing logs. Review their contents before sharing them publicly.

[github-actions]

🧪 CI tested the following changed modules:

• core/camel-api

ℹ️ Dependent modules were not tested because the total number of affected modules exceeded the threshold (50). Use the test-dependents label to force testing all dependents.

---

⚙️ View full build and test results

[apupier]

the Objects.requireNonNull shoudl provide a meaningful message or it is uselles and just blur the codebase

[gnodet]

That's how the JDK handles it, and it's consistent with the rest of the codebase (not completely, but mostly). NullPointerException("uri must not be null") doesn't add information over NullPointerException("uri") — the "must not be null" part is already conveyed by the exception type itself. The parameter name is the useful signal; the rest is noise.

[gnodet]

If we could come up with a real value added message, that would be different, but here, we're just checking an argument, we don't have any information to provide.

[davsclaus]

yeah this is fine and how other frameworks also would do it - also those null values are rarely happening and if so its during development.

[apupier]

the Objects.requireNonNull shoudl provide a meaningful message or it is uselles and just blur the codebase

[davsclaus]

LGTM