Repository navigation
[Bug]JDK: 17 (Corretto 17) Gremlin job tests fail due to Groovy 2.5.14 (Unsupported class file major version 61) #2954
Description
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:
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.
Activity
chandrakiranbolla1 commentedon Feb 24, 2026
I’ve made significant progress on upgrading HugeGraph to TinkerPop 3.8.0.
Completed so far:
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 commentedon Feb 26, 2026
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:
In CI, these are triggered only on branches prefixed with release-* or test-* because the full run is time-consuming.
Our expectation is either:
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.