[XianReallyHot-ZZH]

Ticket: IGNITE-29184

What changes

Since JDK 23, javac no longer runs annotation processors found on the classpath unless they are configured explicitly. The calcite, indexing, zookeeper and control-utility modules relied on this implicit discovery, so on JDK 23+ their builds pass but message serializers / DTO factories are not generated and the node fails at runtime.

This lists the processors each module needs explicitly, configured in pluginManagement so the inherited maven-compiler-plugin picks the list up:

• calcite: MessageProcessor (message and metadata serializers/marshallers) and org.immutables.processor.ProxyProcessor (generates the 14 Immutable* rules and ImmutableIgniteSqlValidator) — listing only the Ignite processor would trade one silent generation gap for another;
• indexing: MessageProcessor;
• zookeeper: MessageProcessor;
• control-utility: IgniteDataTransferObjectProcessor (management API DTO factories; also covers test sources, which declare @Argument DTOs of their own).

ignite-core already lists its processors explicitly (in build/plugins). The four modules here use pluginManagement instead of build/plugins because declaring maven-compiler-plugin in a module's build/plugins makes Maven reorder the module's initialize-phase executions: in calcite, generate-fmpp-sources gets scheduled ahead of copy-fmpp-resources/unpack-parser-template, and the fmpp → javacc parser pipeline fails. Configuring through pluginManagement applies the processor list to the inherited plugin without touching plugin ordering.

Testing

For each module, clean build before/after the change on JDK 21, comparing the full set of generated files:

• calcite: 34 files identical (15 message + 5 metadata serializers/marshallers, 14 immutables classes);
• indexing: 33 files identical;
• zookeeper: 8 files identical;
• control-utility: 2 test-source factories generated (test-compile).

With an explicit processor list, annotation processing no longer depends on the JDK's discovery default, so JDK ≤ 21 behavior is unchanged and JDK 23+ keeps generating. Note: control-utility test-compile needs a current ignite-core snapshot (IGNITE-29050 added SnapshotDeleteCommand); verified green in a reactor build with -am.

[chesnokoff]

Thanks for the contribution. I have two points

1. Please, remove comments because usually they are noisy and hart to maintain
2. Could you check whether a single <proc>full</proc> in the compiler plugin configuration in parent/pom.xml (around line 570) is enough instead of the per-module lists? It might generate the same set of files

[XianReallyHot-ZZH]

Hi @chesnokoff, thanks for the review!

1. Comments removed.

2. Adopted — replaced the per-module lists with a single <proc>full</proc> in the parent's compiler plugin configuration. The processors are then discovered through the ServiceLoader registration files shipped in ignite-codegen (and the immutables jar for calcite), which also means new modules depending on ignite-codegen get annotation processing for free. codegen's own -proc:none was switched from <compilerArgument> to the <proc> element so it overrides the parent deterministically.

Verified on JDK 17.0.12 / 21.0.5 / 23.0.2 / 25.0.4.1 by clean-building the four modules and comparing the generated file sets — identical on every JDK: calcite 34 files, indexing 33, zookeeper 8, control-utility 2 (test sources). (Note: a full reactor build on 23/25 still fails in core's test sources due to the Thread.suspend/resume removal — pre-existing, unrelated to this change.)

One caveat to flag: the -proc:full flag is only accepted from JDK 17.0.12 / 11.0.24 onward (backported), so building with 17.0.0–17.0.11 would fail with "invalid flag". CI uses the current 17.0.x so it is unaffected, but if older patch releases must stay buildable, this could be gated behind a [21,)-activation profile instead.

[XianReallyHot-ZZH]

Hi @chesnokoff, gentle follow-up: both points from your review are addressed in e793283 (comments removed; a single global <proc>full</proc> in the parent POM instead of per-module lists). The branch also now includes the latest master. When you have a moment — could you re-check, and approve the workflow run for the new commits so CI can verify? Thanks!

[chesnokoff]

Thanks for the new version, looks good to me. I had an idea to add to parent/pom.xml:

<requireJavaVersion>
    <version>[17.0.11,)</version>
    <message>Building Ignite requires JDK 17.0.11 or later: javac must accept -proc:full.</message>
</requireJavaVersion>

But looks like some of our ci test agents (Check Javadoc step) use < 17.0.11 so the rule can be added later. For now I run the patch on teamcity

Also, a small correction: -proc:full was backported to 17.0.11 and 11.0.23 (JDK-8324670, JDK-8324804), so the unsupported range is 17.0.0–17.0.10.

[XianReallyHot-ZZH]

Thanks for the correction — right, -proc:full is accepted from 17.0.11 / 11.0.23 (JDK-8324670, JDK-8324804), so the unsupported range is only 17.0.0–17.0.10. Agreed on the enforcer rule — better added later once the CI agents are upgraded. Thanks for running the patch on TeamCity!

[ignitetcbot]

TCBot Test Analysis

• TeamCity: --> Run :: All Results
• Branch: pull/13732/head
• Base: master
• Tested commit: 873ebbf

Possible Blockers (0)

No blockers found.

New Tests (1)

• Cache 13: 1 tests
  • IgniteCacheTestSuite13: SystemViewCacheExpiryPolicyTest.testCacheViewExpiryPolicy[factory=javax.cache.configuration.FactoryBuilder$SingletonFactory@632cf7d3, actual=SingletonFactory [expiryPlc=EternalExpiryPolicy [create=ETERNAL]]] - PASSED

[chesnokoff]

LGTM. I'll find a committer to merge it

[chesnokoff]

@XianReallyHot-ZZH Thanks for contribution! Merged to master. Please, for future contributions follow https://github.com/apache/ignite/blob/master/CONTRIBUTING.md guide to assign tickets to you