Hi Goutam, Thank you for your detailed proposal and proactive research. Here are some brief inputs on your questions:
1. Blockers in Traversal Layer: The main challenge is that HugeGraph has optimized and overridden certain steps (like has()) for performance. However, this should be controllable and shouldn't lead to major breaking changes if handled carefully. 2. Security vs. Performance: Whether to keep the blacklist alongside AST transformation depends on the balance between security and performance. Our security perspective (SEC) is to minimize performance loss. If the overhead is too high, basic isolation via Auth + Docker would be a reasonable baseline. 3. Benchmarking & Java Version: Using the twitter-2010 dataset for testing is appropriate. Regarding Java migration, the Server doesn't strictly need to maintain Java 11 compatibility; the primary focus should be resolving the TinkerPop dependency and compatibility issues during the upgrade. Your background with Apache projects and RAG pipelines is very relevant. Looking forward to your update! Best regards, Imba Jin - Apache HugeGraph PMC member On 2026/03/29 20:17:16 Goutam K wrote: > Hi Imba and Yan, > > I'm Goutam K, a GSoC 2026 applicant for the HugeGraph Query Engine Upgrade > project. > > About me: Software Engineer at Accenture with Java backend experience, and > 6 merged PRs in apache/burr. Most relevant are PRs #629 and #615 both > involve RAG pipelines that use graph-like iterative retrieval, which is the > primary workload HugeGraph serves as a knowledge graph backend. I use AI > coding tools (Claude Code, Copilot) daily for navigating and refactoring > large codebases, which matches the recommended skills for this project. > > My approach is four independent phases: > > 1. TinkerPop 3.5 to 3.7 upgrade run the full test suite on 3.7 first, > treat every failure as the complete breaking-change inventory, fix > systematically; > 2. Java 17 migration resolve module access restrictions, update Docker > images, maintain Java 11 fallback throughout; > 3. HugeGraphSecurity refactoring replace the runtime blacklist with a > Groovy 4 AST transformation running at compile time, loaded via feature > flag with blacklist as rollback; > 4. Twitter-14B benchmark comparing Java 11 and Java 17. > > I reviewed the TinkerPop upgrade docs against the HugeGraph Gremlin > translation layer source and found what appear to be usages of has() with > null values and at least two deprecated traversal steps still in use. > > I have confirmed 20–25 hrs/week availability during the GSoC period with no > time off planned. > > Two questions I'd value your input on: > > - Are there known blockers in the traversal layer beyond what the > TinkerPop upgrade docs cover that the community is already aware of? > - For Phase 3, is there a preference between removing the blacklist > entirely once the AST transformation is validated, or keeping both in > parallel permanently? > > Thanks for your time. > > Goutam K [email protected] | github.com/goutamk09 >
