[miguelnieto]

Summary

Moves the plugin to Eclipse MAT 1.17.0, Java 21, Eclipse 4.40 and Apache Calcite 1.42.0. It also fixes ORDER BY and joins on heap objects, which Calcite 1.37+ broke.

This is the first of three stacked PRs:

1. This PR: platform upgrade
2. SQL editor: schema browser, Open in SQL Editor, cancel, date functions (2/4) #122: SQL editor improvements (builds on this one)
3. Add an MCP server for AI assistants to query heap dumps (3/4) #123: MCP server for AI assistants (builds on SQL editor: schema browser, Open in SQL Editor, cancel, date functions (2/4) #122)
4. Update shipped libraries with known vulnerabilities (4/4) #129: updates of shipped libraries with known vulnerabilities (builds on Add an MCP server for AI assistants to query heap dumps (3/4) #123)

Each PR builds and passes its tests on its own.

Supersedes the calcite-core 1.42.0 bumps in #119 and #120. Those change only the pom; the Tycho target definition and the new Avatica runtime dependencies need changing too (see below).

⚠️ Breaking

• MAT 1.17.0+ and Java 21 are required. org.eclipse.mat.api 1.17.0 declares Bundle-RequiredExecutionEnvironment: JavaSE-21, so the plugin can't target lower. Users on older MAT stay on 1.6.x; the README says so.
• The build's target platform moves from Eclipse 2022-12 to Eclipse 4.40, the release MAT 1.17.0 builds against.

Changes

Platform

• MAT bundles come from the MAT 1.17.0 update site instead of an Eclipse simultaneous release, so the MAT API version matches what users run. The target lists only the MAT units the plugin uses. The full feature group would pull in BIRT and Rhino.
• Java 21 everywhere: execution environment, compiler level, CI matrix, README.
• Calcite and Guava versions are aligned between MatCalcitePlugin/pom.xml and the target definition. They had drifted apart (pom 1.41.0, target 1.36.0), because Renovate updates poms but not Tycho targets. So the plugin could compile against one Calcite and run against another. Guava is 33.7.2-jre in both: Renovate has since updated it in the pom on main, but not in the target.

Calcite 1.42 runtime

• Avatica 1.29.0 instead of the 1.28.0 Calcite asks for. Avatica before 1.29.0 has CVE-2026-70410 (unsafe reflection in plugin instantiation, CVSS 8.8), and Calcite 1.42.0 is still the newest release. avatica-core is declared before calcite-core, so Maven compiles against the Jackson 2.22.2 that Avatica 1.29.0 brings and the target platform ships. The plugin itself isn't exposed: it opens its Calcite connection with fixed properties, so no class names reach Avatica from SQL or other input.
• The target and Import-Package gain httpclient5/httpcore5 (new in Avatica 1.28) and joou. Without them the plugin fails at runtime with NoClassDefFoundError for org/apache/hc/core5/util/Timeout and org/joou/UInteger.
• jakarta.transaction-api is excluded from commons-dbcp2. It has an unsatisfiable Import-Package (javax.enterprise.context), and it kept geronimo-jta_1.1_spec from supplying javax.transaction.

ORDER BY and joins on heap objects

Calcite 1.37+ compares Map-typed values with Functions.compareMaps(), which walks entrySet(). HeapReference implements Map only for the this['field'] syntax, and its entrySet() threw an exception. So every ORDER BY over a heap object failed with UnsupportedOperationException.

entrySet() now returns a single entry that orders like compareTo. Two details matter:

• Both must give the same order. Calcite sorts merge-join inputs through entrySet() but merges them with compareTo. When the two orders differed, the merge join dropped matches: java.lang.Class left join instanceof.java.lang.ClassLoader matched 469 rows instead of 985.
• Both order by address. That is constant time, while the old label order rebuilt each label (a String's text) on every comparison. ORDER BY this over 4M objects took about 2 minutes instead of 10 s. ORDER BY toString(this) still sorts by label.

SQL functions

• New getHexAddress(x): the address as 0x…, the form MAT shows.
• getDominator(x) failed with "Object -1 not found" for objects dominated by the virtual root; it now returns null.

Tests

• testStackTraces now ignores the source file MAT adds to native frames. MAT 1.17 renders (Object.java(Native Method)) where older versions rendered (Native Method). The plugin passes that text through unchanged.
• New tests:
  • ORDER BY this, in both directions;
  • a merge join over a strict subset (a self-join can't detect an order mismatch);
  • the class / class loader join, written three ways, all giving 985.

Testing

• ./mvnw verify with JDK 21: 51 tests pass, 1 skipped (testConcurrentHashMap, skipped as on main).
• Installed into MAT 1.17.0 on Linux (GTK/Wayland): queries, ORDER BY this and joins on a 1.5 GB dump with 24M objects.

Notes for reviewers

• The build log prints a few [ERROR] [verify-osgi-pom] lines. They don't fail the build, and they predate this PR: main prints 10, this branch prints 3. The 3 left can't be fixed in the poms:

  • calcite-core on Maven Central has no OSGi manifest;
  • commons-dbcp2 requires javax.transaction.xa;partial=true, which nothing provides.

  They only concern Maven consumers that run the jars in a plain OSGi framework, not the p2 site. Removing the verify-osgi-pom execution would hide them; that's your call.

🤖 Generated with Claude Code

[vlsi]

@miguelnieto , thanks for pushing this forward. Will review soon.