Skip to content

IGNITE-28893 Calcite. Declare joou runtime dependency explicitly#13372

Open
anton-vinogradov wants to merge 1 commit into
apache:masterfrom
anton-vinogradov:ignite-calcite-joou
Open

IGNITE-28893 Calcite. Declare joou runtime dependency explicitly#13372
anton-vinogradov wants to merge 1 commit into
apache:masterfrom
anton-vinogradov:ignite-calcite-joou

Conversation

@anton-vinogradov

Copy link
Copy Markdown
Contributor

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

calcite-core 1.42 added org.jooq:joou-java-6 as a runtime dependency, but
only direct dependencies are copied into target/libs, which both the release
package and the exploded test classpath are assembled from. Without it a node
with the Calcite engine halts the JVM on NoClassDefFoundError at startup.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@zstan

zstan commented Jul 15, 2026

Copy link
Copy Markdown
Contributor

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

Copy link
Copy Markdown
Contributor Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants