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
