IGNITE-28893 Calcite. Declare joou runtime dependency explicitly

[anton-vinogradov]

Symptom

The Platform C++ CMake suites report 595 tests instead of 1046, with zero failures. The TeamCity "test count dropped" guard turns the suite red without a single failed test, which in turn poisons PR verdicts. Most PRs do not see it because their chains reuse older C++ results.

Root cause

The Calcite upgrade from 1.40 to 1.42 changed only the version properties in modules/calcite/pom.xml. But calcite-core 1.42 declares a new runtime dependency, org.jooq:joou-java-6:0.9.5, which 1.40 did not have, and it was not added to the module's dependency list.

That matters because the copy-libs execution of maven-dependency-plugin in parent/pom.xml copies only direct dependencies into target/libs (excludeTransitive is true). This is exactly why modules/calcite/pom.xml already declares Calcite's runtime dependencies explicitly — guava, failureaccess, janino, avatica-core, jackson, json-path, reflections. joou was not declared, so it never lands in modules/calcite/target/libs.

Two consumers are built from target/libs:

1. The release package. assembly/dependencies-apache-ignite.xml maps each optional module's target/libs into optional/${module.artifactId}, so libs/optional/ignite-calcite ships without joou.
2. The exploded classpath of the embedded dev node, assembled by CreateIgniteHomeClasspath() in modules/platforms/cpp/core/src/jni/os/{linux,win}/utils.cpp, which appends each module's target/libs jars. This is the classpath the C++ tests boot their JVM node with.

A node with the Calcite engine enabled therefore dies during startup:

java.lang.NoClassDefFoundError: org/joou/ULong
Critical system error detected ... failureCtx=FailureContext [type=SYSTEM_WORKER_TERMINATION,
    err=java.lang.NoClassDefFoundError: org/joou/ULong]
JVM will be halted immediately due to the failure

StopNodeOrHaltFailureHandler halts the JVM from inside the hosting process, so the C++ test binary that started the node is killed along with it and its remaining tests never run.

The only C++ configuration that enables the Calcite engine is odbc-test/config/queries-default.xml. That is why exactly one binary dies: the ODBC one, at its first node-starting test (ConnectionTestSuite: TestConnectionRestore, which boots queries-test.xml). The suite's 595 tests break down as core-test 458 + thin-client-test 130 + odbc-test 7.

Java suites are unaffected because Surefire resolves the full transitive classpath from Maven — only the target/libs-based layouts are broken.

Fix

Declare org.jooq:joou-java-6 explicitly in modules/calcite/pom.xml, so it is copied into target/libs and reaches both the release package and the exploded test classpath.

What was verified vs. inferred

Verified locally:

• calcite-core 1.40.0 has no joou; 1.42.0 declares joou-java-6:0.9.5 with scope=runtime.
• Before the fix modules/calcite/target/libs contains 19 jars, joou absent; after the fix 20 jars, joou-java-6-0.9.5.jar present.
• Booting a node from the ODBC suite's own queries-test.xml on an exploded classpath without joou reproduces NoClassDefFoundError: org/joou/ULong → critical system error → JVM halt (exit 130). With joou on the classpath the same node starts normally.

Verified from the CI build: the failing build's test list (core-test 458, thin-client-test 130, odbc-test 7) and the build log, which contains the NoClassDefFoundError: org/joou/UByte stack and the subsequent halt. (The class differs from the local run — UByte vs ULong — because the first reflective touch of the missing library varies by code path; the library and the failure are the same.)

Not verified: the C++ toolchain was not built locally, so the death of the boost binary itself was observed only in the CI log, not reproduced on my machine. Windows behaviour is inferred from the Linux run plus the identical packaging path.

Out of scope: 26 further transitive runtime dependencies of calcite-core (proj4j, avatica remote HTTP, snakeyaml, …) are likewise absent from target/libs. They have always been absent and are not reached at runtime; only joou became newly required. Worth keeping in mind on the next Calcite/Avatica bump.

cc @zstan (Calcite upgrade), @timoninmaxim (the target/libs / exploded-classpath machinery)

🤖 Generated with Claude Code

[zstan]

I see, it really appended in last versions, but currently it functional is not used (i believe in java), plz give me a clue why it work`s perfectly well for java ?

[anton-vinogradov]

Ignite PR Checker verdict · RunAll build 9210086 · 147 suites ran, 0 reused

🔍 1 suite(s) ran fewer tests than on master (tests that never ran can't fail):

• PDS 1: 111 tests vs 335 on master (−67%)

✅ No test blockers otherwise; 29 pre-existing/flaky filtered out.

[anton-vinogradov]

@zstan You're right that Ignite's own Java code doesn't call these methods — but Calcite does, at engine init.

In calcite-core 1.42 the class org.apache.calcite.runtime.SqlFunctions gained 59 methods whose signatures use joou unsigned types (org.joou.ULong plus(ULong, ULong), checkedPlus(...), etc.). These are new in 1.42 — 1.40 had no joou at all.

The node dies while building the engine, not while running a query. Stack (reproduced locally without joou on the classpath):

java.lang.NoClassDefFoundError: org/joou/ULong
    at java.base/java.lang.Class.getDeclaredMethods0(Native Method)
    at org.apache.calcite.linq4j.tree.Types.lookupMethod(Types.java:288)
    at org.apache.calcite.util.BuiltInMethod.<init>(BuiltInMethod.java:1043)
    at org.apache.calcite.util.BuiltInMethod.<clinit>(BuiltInMethod.java:320)
    at o.a.i.i.processors.query.calcite.exec.exp.RexImpTable.<init>(RexImpTable.java:300)
    ... IgniteScalarFunction.create -> SchemaHolderImpl.onFunctionCreated -> cache start

BuiltInMethod.<clinit> calls Class.getDeclaredMethods0, which resolves every method signature of the referenced classes, including the joou-typed ones — so the class must be on the classpath even though nothing invokes those methods.

Why Java suites are green: Surefire builds its classpath from the full transitive Maven graph, where joou is present transitively via calcite-core — declared explicitly or not. The failure only appears in classpaths assembled from target/libs, which copy-libs fills with direct dependencies only (excludeTransitive=true). That's exactly why this module already hand-declares guava, janino, avatica, jackson, etc. — joou was the one that got missed. Both the C++ dev node and libs/optional/ignite-calcite in the release are built from target/libs, so both break; Surefire never does.

[anton-vinogradov]

@zstan And here is the same failure taken from CI on current master (no local setup involved): build 9209640, Platform C++ CMake (Linux Clang), branch refs/heads/master, 2026-07-14 — the ODBC binary's first node-starting test:

[TestConnectionRestore] [ERROR][exchange-worker-#45%NodeMain%][GridDhtPartitionsExchangeFuture] Failed to reinitialize ...
[TestConnectionRestore] java.lang.NoClassDefFoundError: org/joou/UShort
[TestConnectionRestore]   at java.base/java.lang.Class.getDeclaredMethods0(Native Method)
[TestConnectionRestore]   at org.apache.calcite.linq4j.tree.Types.lookupMethod(Types.java:288)
[TestConnectionRestore]   at org.apache.calcite.util.BuiltInMethod.<init>(BuiltInMethod.java:1043)
[TestConnectionRestore]   at org.apache.calcite.util.BuiltInMethod.<clinit>(BuiltInMethod.java:320)
[TestConnectionRestore]   at o.a.i.i.processors.query.calcite.exec.exp.RexImpTable.<init>(RexImpTable.java:300)
...
[TestConnectionRestore] [ERROR][ttl-cleanup-worker-#49%NodeMain%][] JVM will be halted immediately due to the failure ...
[TestConnectionRestore] 1/1 Test #3: IgniteOdbcTest ...................***Failed    5.19 sec

Same frames as the local repro. (The missing class name varies between runs — UByte/UShort/ULong — because it's whichever joou-typed signature BuiltInMethod's static init touches first; the library and the failure point are the same.)

The JVM halt kills the hosting ignite-odbc-tests process after its 7th test, which is where the 1046 → 595 test count on master comes from. The same suite on this PR's branch runs all 1046 (build 9209313).