[Bug]JDK: 17 (Corretto 17) Gremlin job tests fail due to Groovy 2.5.14 (Unsupported class file major version 61)

[chandrakiranbolla1]

Bug Type (问题类型)

others (please edit later)

Before submit

• 我已经确认现有的 Issues 与 FAQ 中没有相同 / 重复问题 (I have confirmed and searched that there are no similar problems in the historical issue and documents)

Environment (环境信息)

• HugeGraph Version: master (latest commit)
• Build Mode: mvn clean test
• JDK: 17 (Corretto 17)
• OS: macOS
• Backend: In-memory (test execution)

Note:
All tests pass when running under Java 11.
Failures occur only under Java 17.

Expected & Actual behavior (期望与实际表现)

Expected Behavior:
All core tests should pass when running under Java 17.

Actual Behavior:
Gremlin job-related tests fail with task status FAILED instead of SUCCESS or CANCELLING.

Failing tests:

• TaskCoreTest.testGremlinJob
• TaskCoreTest.testGremlinJobAndCancel
• TaskCoreTest.testGremlinJobAndRestore
• TaskCoreTest.testGremlinJobWithScript
• TaskCoreTest.testGremlinJobWithSerializedResults

Exception:
javax.script.ScriptException:
java.util.concurrent.ExecutionException:
BUG! exception in phase 'semantic analysis' in source unit 'Script1.groovy'
Unsupported class file major version 61

Major version 61 corresponds to Java 17 bytecode.

Dependency Analysis:
org.apache.tinkerpop:gremlin-groovy:3.5.1
org.codehaus.groovy:groovy:2.5.14

Groovy 2.5.x does not fully support Java 17 bytecode analysis.

Context:

Related discussion / issues / pr:

• [Question] Java 17 plans? #2723
• chore(server): upgrade tinkerpop from 3.5 → 3.7.2 #2884

Related roadmap item:
https://issues.apache.org/jira/browse/GSOC-317

Vertex/Edge example (问题点 / 边数据举例)

Not applicable.

This issue is related to build/runtime incompatibility between Java 17 and Groovy 2.5.14.
It does not involve specific vertex/edge data, REST queries, or schema definitions.

Schema [VertexLabel, EdgeLabel, IndexLabel] (元数据结构)

Not applicable.

This issue is related to build/runtime incompatibility between Java 17 and Groovy 2.5.14.
It does not involve specific vertex/edge data, REST queries, or schema definitions.

[chandrakiranbolla1]

I’ve made significant progress on upgrading HugeGraph to TinkerPop 3.8.0.

Completed so far:

• Removed gremlin-shaded:3.5.1
• Migrated traversal optimize layer (Step generics, Aggregate changes)
• Updated ConditionP to use PBiPredicate
• Adapted HugePrimaryKeyStrategy for Mutating API changes
• Migrated driver classes (RequestMessage, ResponseMessage, Tokens) to gremlin-util
• hugegraph-core builds and tests pass successfully

Verification:

mvn -pl hugegraph-server/hugegraph-core -am test -Drat.skip=true
→ BUILD SUCCESS

Full project build:

mvn clean install -Drat.skip=true

Build proceeds successfully through core and API modules.
The remaining failure is in hugegraph-test, due to moved/removed TinkerPop test classes (e.g., StoreTest) in 3.8.

Spike branch (for review):
https://github.com/chandrakiranbolla1/incubator-hugegraph/tree/spike/tinkerpop-3.7-upgrade

Commit reference (for quick review):
chandrakiranbolla1@e77f1eb

Question:

Should I continue aligning HugeGraph’s test suite with TinkerPop 3.8 changes,
or is there a preferred intermediate target version (e.g., 3.6/3.7)?

I’m happy to proceed and open a draft PR once test alignment is complete.

@imbajin @zyxxoo would appreciate your guidance on whether targeting 3.8 aligns with the current roadmap.

[imbajin]

Question:

Should I continue aligning HugeGraph’s test suite with TinkerPop 3.8 changes, or is there a preferred intermediate target version (e.g., 3.6/3.7)?

I’m happy to proceed and open a draft PR once test alignment is complete.

@imbajin @zyxxoo would appreciate your guidance on whether targeting 3.8 aligns with the current roadmap.

Thanks for the progress. Here is guidance from us:

1. Version strategy

We should prioritize compatibility with TinkerPop 3.8.
If TinkerPop 4.0 GA is available and practical, we can evaluate moving directly to 4.0.
If we encounter severe and hard-to-resolve conflicts, we can step down gradually, but not below 3.7.
(Our current understanding is that Java 17 support starts around 3.7.)

2. Draft PR expectations

A Draft PR does not need all tests to pass.
It is also fine to open a parallel PR in your own fork, where you have full permissions for faster debugging and CI experimentation.

3. TinkerPop compatibility scope

The key suites are:

• tinkerpop-structure-test
• tinkerpop-process-test

In CI, these are triggered only on branches prefixed with release-* or test-* because the full run is time-consuming.
Our expectation is either:

• all tests pass, or
• every failing test has a clear root-cause explanation.

Your next priority is to map pass/fail status and avoid rerunning already-confirmed passing tests to shorten iteration time.

4. Breaking changes tracking

Please keep a 3.5 -> 3.8/4.0 breaking-change list.
Some API changes are unavoidable, and we need explicit trade-off decisions.
This is important but not urgent.

5. Final acceptance target

Before final merge, we expect full pass at least on memory and RocksDB/HStore.