contrueCT opened a new issue, #3069: URL: https://github.com/apache/hugegraph/issues/3069
### Feature Description (功能描述) ## Background HugeGraph's core query engine has historically been built on an older runtime and query stack: Java 11, TinkerPop 3.5.x, and Groovy 3. While this foundation already provides the essential graph query capabilities, it also limits long-term maintainability, security hardening, and access to newer runtime and language improvements. In particular, the Groovy-based script execution path relies on complex blacklist / whitelist mechanisms for sandboxing. This model is difficult to maintain and reason about over time, especially when upgrading Groovy, TinkerPop, and the Java runtime together. Modernizing the query engine dependency stack is therefore not only a version upgrade, but also an opportunity to reduce long-term maintenance cost, align with newer TinkerPop behavior, prepare for stronger Java runtime support, and establish a cleaner baseline for future compatibility and performance work. This issue tracks the ongoing HugeGraph query engine modernization work. The current focus is to establish a stable baseline on **Apache TinkerPop 3.7.6** and **Groovy 4.0.25**, while keeping the follow-up path toward Java 17 readiness, Groovy sandbox review, distributed-module validation, benchmark methodology, and future TinkerPop 3.8 exploration clear. ### Tracking Links Detail Planning note: https://hugegraph.feishu.cn/wiki/WoWpwSNZlidSHskAivccaQS9nig ## Current Direction The current plan is to treat the TinkerPop 3.7.6 and Groovy 4 upgrade as the baseline migration step. This keeps the first milestone focused on dependency alignment, API adaptation, serializer compatibility, runtime behavior, and test stabilization. Follow-up work should be tracked separately so that each area has a clear scope, owner, and validation signal. ## What the Current Baseline PR Changes The current baseline migration mainly covers the following areas: - Upgrade the TinkerPop dependency line to 3.7.6. - Upgrade Groovy-related dependencies to Groovy 4.0.25. - Adapt code affected by TinkerPop package, API, traversal, predicate, and serializer changes. - Adjust HugeGraph-specific predicate and traversal integration where TinkerPop behavior or APIs changed. - Update Groovy integration code for Groovy 4 compatibility. - Preserve remote-client and serializer behavior across the upgraded dependency set. - Normalize related Cypher and remote response behavior where required by the new baseline. - Update affected tests and CI expectations for the 3.7.x dependency line. - Keep distributed modules in view, especially PD, Store, and HStore validation after the server-side baseline is stable. ## Planning Decisions - Use TinkerPop 3.7.6 + Groovy 4.0.25 as the first stable modernization baseline. - Avoid mixing every follow-up concern into the baseline PR. - Track Java 17, Groovy sandbox, distributed-module validation, benchmarks, release metadata, and TinkerPop 3.8 as separate follow-up workstreams. - Treat TinkerPop 3.8 as an exploration and readiness target first, not as part of the initial baseline upgrade. ## Proposed Sub-issues - [ ] Baseline migration: TinkerPop 3.7.6 and Groovy 4.0.25 compatibility. - [ ] Java 17 readiness: runtime smoke tests, CI impact, Docker impact, and test coverage. - [ ] Groovy sandbox review: security model review after moving to Groovy 4. - [ ] TinkerPop 3.8 readiness: delta map, compile spike, semantic regressions, provider-test plan, and acceptance gates. - [ ] PD / Store / HStore validation: distributed-module scope and compatibility checks. - [ ] Benchmark methodology: reproducible performance plan and regression threshold. - [ ] Release metadata: dependency list, LICENSE, NOTICE, and release notes. ## Expected Outcome The expected result is a clearly staged modernization path: 1. Land a stable TinkerPop 3.7.6 + Groovy 4 baseline. 2. Validate runtime and test behavior across the core server and related modules. 3. Prepare Java 17 and Groovy sandbox follow-up work. 4. Establish a reproducible benchmark process after the baseline behavior is stable. 5. Use the TinkerPop 3.8 exploration note to decide the next upgrade boundary and acceptance criteria. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
