Goal: Standardize idempotency enforcement to prevent replay attacks in core financial modules. Implementation Strategy (Addressing James Dailey's feedback):

1. Opt-In Architecture: New logic will be behind a Global Configuration flag. Default remains legacy behavior to ensure 100% backward compatibility.

1. Phased Approach: Audit existing m_portfolio_command_source usage and bridge gaps in the Savings module first.

1. Testing: Implementation of integration tests simulating network failures/retries.

Background and Motivation

Fineract accumulated some technical debt over the years. One area that is implicated is type-safety of internal and external facing APIs, the most prominent of which is Fineract's REST API. In

Background and Motivation

Fineract accumulated some technical debt over the years. One area that is implicated is type-safety of internal and external facing APIs, the most prominent of which is Fineract's REST API. In general the package layout of the project reflects a more or less classic layered architecture (REST API, data transfer/value objects, business logic services, storage/repositories). The project predates some of the more modern frameworks and best practices that are available today and on occasions the data structures that are exchanged offer some challenges (e.g. generic types). Fineract's code base reflects that, especially where JSON de-/serialization is involved. Nowadays, this task would be simply delegated to the Jackson framework, but when Fineract (Mifos) started the decision was made to use Google's GSON library and create handcrafted helper classes to deal with JSON parsing. While this provided a lot of flexibility this approach had some downsides:

• the lowest common denominator is the string type (aka JSON blob); this is where we lose the type information
• the strings are transformed into JSONObjects; a little bit better than raw strings, but barely more than a hash map
• a ton of "magic" strings are needed to get/set values
• this approach makes refactoring unnecessarily more difficult
• to be able to serve an OpenAPI descriptor (as JSON and YAML) we had to re-introduce the type information at the REST API level with dummy classes that contain only the specified attributes; those classes are only used with the Swagger annotations and no were else
• some developers skipped the layered architecture and found it too tedious to maintain DTOs and JSON helper classes, and as a result just passed JSONObjects right to the business logic layer
• now the business logic is unnecessarily aware of how Fineract communicates to the outside world and makes replacing/enhancing the communication protocol (e.g. with GRPC) pretty much impossible

The list doesn't end here, but in the end things boil down to two main points:

• poor developer experience: boilerplate code and missing type safety cost more time
• bugs: the more code the more likely errors get introduced, especially when type safety is missing and we have to rely on runtime errors (vs. compile time).

There has been already some preparatory work done concerning type safety, but until now we avoided dealing with the real source of this issue. Fineract's architectures devises read from write requests ("CQRS", https://martinfowler.com/bliki/CQRS.html) for improved scalability.

The read requests are not that problematic, but all write requests pass through a component/service that is called "SynchronousCommandProcessingService. As the name suggests the execution of business logic is synchronous (mostly) due to this part of the architecture. This is not necessarily a problem (not immediately at least), but it's nevertheless a central bottleneck in the system. Even more important: this service is responsible to route incoming commands to their respective handler classes which in turn execute functions on one or more business logic services. The payload of these commands are obviously not always the same... which is the main reason why we decided to use the lowest common denominator to be able to handle these various types and rendered all payloads as strings. This compromise bubbles now up in the REST API and the business logic layers (and actually everything in between).

Over the years we've also added additional features (e.g. idempotency guarantees for incoming write requests) that make it now very hard to reason about the execution flow. Testing the performance impact of such additions to the critical execution path even can't be properly measured. Note: the current implementation of idempotency relies on database lookups (quite often, for each incoming request) and none of those queries are cached. If we wanted to store already processed requests (IDs) in a faster system (let's Redis) then this can't be done without major refactoring.

In conclusion, if we really want to fix those issues that are not only cosmetic and affect the performance and the developer experience equally then we urgently need to fix the way how we process write requests aka commands.

Target Personas

• developers
• integrators
• end users
• BaaS

Goals

• new command processing will run independently next to the legacy mechanics
• self contained
• fully tested
• ensure that the REST API is 100% backward compatible
• try to contain the migration and make it as easy as possible for the community to integrate those changes
• introduce types where needed and migrate the (old) JAX-RS REST resource classes to Spring Web MVC (better performance and better testability)
• introduce DTOs if not already available and make sure if they exist that they are not outdated
• assemble one DTO as command payload from all incoming REST API parameters (headers, query/path paramters, request bodies)
• annotate attributes in the DTOs with Jakarta Validation annotations to enforce constraints on their values
• wired REST API to the new command processing, one service at a time/pull request
• take a non-critical service (like document management) and migrate it to the new command processing mechanics from top (REST API) to bottom (business logic service)
• refactor command handlers to new internal API
• make sure that the business service logic classes/functions take only one DTO request input parameter (aka don't let a function have 12 input parameters of type string...)
• when all integration tests run successfully then remove all legacy boilerplate code that is not used anymore
• make an ordered list of modules/features (easiest, lowest hanging fruit first)
• maintain at least the same performance as the current implementation
• optional: improve performance if it can be done in a reasonable time frame
• optional: improve resilience if it can be done in a reasonable time frame

Non-Goals

• current command processing will stay untouched, will run independently of new infrastructure
• don't try cleaning up the storage layer; that's a separate effort for later (type safe queries, query peformance, clean entity classes)
• maker-checker is tightly coupled in the current command processing implementation upstream; this is a separate concern for a separate proposal (domains: security, workflow)
• doesn't need to be optimized for speed immediately
• no changes in the integration tests

Proposed API Changes

Command Wrapper

Class contains some generic attributes like:

• username
• tenant ID
• timestamp

The actual payload (aka command input parameters) are defined as a generic parameter "payload". It is expected that the modules implement classes that introduce the payload types and inherit from the abstract command class.

Command Processing Service

Three performance levels are configurable via application.properties

• synchronously (required): this is pretty much as we do right now (use virtual threads optionally)
• asynchronously (optional): with executor service and completable futures (use virtual threads optionally)
• non-blocking (optional): high performance LMAX Disruptor non-blocking implementation

These different performance level implementations need to be absolute drop-in replacements (for each other). It is expected that more performant implementations need more testing due to increased complexity and possible unforeseen side effects (thread local variables, transactions). In case any problems show up we can always roll back to the required default implementation (synchronous).

NOTE: we should consider providing a command processing implementation based on Apache Camel once this concept is approved and we migrated already a couple of services. They are specialized for exactly this kind of use cases and have more dedicated people working on it's implementation. Could give more flexibility without us needing to maintain code.

Middlewares

TBD

Command Handlers

TBD

References to users (aka AppUser)

Keep things lightweight and only reference users by their user names.f

Risks

TBD

• feature creep

ETA

A first prototype of the a new command processing component is ready for evaluation. There is also an initial smoke test (JMH) available.

You can try it out with the following instructions (it's still in a private repository, but will be published soon as an official PR):

git clone git@github.com:vidakovic/fineract.git
cd fineract
git checkout feature/FINERACT-2169
./gradlew :fineract-command:build
./gradlew :fineract-command:jmh

Diagrams

TBD

Related Jira Tickets

• https://issues.apache.org/jira/browse/FINERACT-2021
• https://issues.apache.org/jira/browse/FINERACT-1744
• https://issues.apache.org/jira/browse/FINERACT-1909
• https://issues.apache.org/jira/browse/FINERACT-2452

Goal: Standardize idempotency enforcement to prevent replay attacks in core financial modules. Implementation Strategy (Addressing James Dailey's feedback):

1. Opt-In Architecture: New logic will be behind a Global Configuration flag. Default remains legacy behavior to ensure 100% backward compatibility.

1. Phased Approach: Audit existing m_portfolio_command_source usage and bridge gaps in the Savings module first.

1. Testing: Implementation of integration tests simulating network failures/retries.

ESP Hosted is a firmware that allows ESP32xx modules shared WiFi and BLE with the host OS, like Linux, RTOS or even some baremetal MCU.

Add ESP Hosted support on NuttX will allow any platform supported by NuttX to WiFi and/or BLE from ESP32xx modules.

More info: https://github.com/espressif/esp-hosted

Description

Currently, the HugeGraph core query engine is built on Java 11 + TinkerPop 3.5.x + Groovy 3. While this stack provides fundamental graph query capabilities, it lags behind in security, performance optimization, and support for modern features. Specifically, the built-in Groovy engine relies on complex, high-maintenance black/whitelist mechanisms for script security, which poses potential bypass risks.

The goal of this task is to comprehensively upgrade HugeGraph's underlying dependencies to Java 17 + TinkerPop 3.7/3.8 + Groovy 4. This is not just a version iteration, but a modern architectural transformation:

1. Groovy 4 & TinkerPop 3.7/3.8: Introduce improved syntax features and security designs. We aim to refactor HugeGraphSecurity using native, efficient sandboxing mechanisms to replace the legacy blacklist logic.
2. Java 17/21 Support: Adapt to the new JDK to fully leverage features like ZGC/Shenandoah GC, Records, and Virtual Threads, significantly improving throughput and reducing long-tail latency in large-scale graph queries.

Applicants are expected to handle the full lifecycle, from dependency upgrades and code refactoring to unit test fixes and final performance benchmarking.

Recommended Skills

1. Java Core: Proficiency in Java development with a solid understanding of Java 17+ new features.
2. HugeGraph Architecture: Basic understanding of HugeGraph's storage structure (KV Store), Schema design, and specifically the Gremlin query execution flow.
3. Graph Computing & Compilers: Familiarity with the TinkerPop Gremlin framework architecture; knowledge of AST (Abstract Syntax Tree) parsing or Functional Programming (FP) mindset is a plus.
4. AI Coding: Proficiency in using AI Coding tools (e.g., Codex, Claude Code, Copilot) to assist in code refactoring, test case optimization, and source code interpretation is highly preferred.
5. Security Awareness: Awareness of code security, understanding of how to prevent Script Injection, and experience designing secure sandbox environments.

💡 Important Notes for Applicants

1. Authenticity Matters: While we encourage the use of AI for coding efficiency, please strictly control and reasonably limit the use of LLMs when writing your project proposal/emails. We value genuine communication and mutual respect.
2. Proactive Engagement: We highly recommend participating in community Mini Tasks early. Demonstrating your hands-on ability within the community will significantly increase your chances of selection and help build trust with mentors.

Task List

• Dependency Analysis & Upgrade:
  • Analyze Breaking Changes from TinkerPop 3.5 to 3.7/3.8.
  • Complete core dependency version upgrades and API adaptations following mentor confirmation.

• Java 17 Environment Adaptation:
  • Resolve compile-time and runtime compatibility issues (e.g., reflection restrictions, module access) to ensure the Server module runs correctly on Java 17 (Java 21 is even better).
  • Update Docker configurations to migrate the default runtime to Java 17 (while exploring backward compatibility with Java 11).

• PD & Store Module Upgrade (New):
  • Extend the upgrade scope to the PD (Placement Driver) and Store modules after completing the core Server upgrade.
  • Ensure these modules are adapted to Java 17 to unify the runtime environment across the HugeGraph ecosystem.

• Security Module Refactoring:
  • Refactor the HugeGraphSecurity component based on Groovy 4 features.
  • Design a lightweight, secure script execution strategy and remove the performance-heavy legacy blacklist logic.

• Testing & Fixes:
  • Fix Unit Test (UT) failures caused by the upgrade.
  • Ensure all core functions (CRUD, complex Gremlin queries) pass verification.

• Performance Benchmarking:
  • Produce a performance comparison report: Java 11 (Old) vs. Java 17 (New) using the Twitter-14B public dataset.
  • Quantify improvements in Latency reduction and Throughput increases.

References

• New Contributor Guide: HugeGraph Contribution Guide (Issue #2212) - Environment setup & basics.

• Upgrade Docs: TinkerPop Upgrade Documentation

• Reference Implementation: JanusGraph Upgrade PR (For reference only)

• Gremlin Learning: Practical Gremlin Guide

• Project Wiki: HugeGraph Deepwiki

Project Size

• Difficulty: Medium (Similar references available)

• Estimated Time: ~250 Hours (~15 Weeks)

Mentors

• Yan Zhang: vaughn@apache.org (Apache HugeGraph PMC)

• Imba Jin: jin@apache.org (Apache HugeGraph PMC)

Summary

Currently a lot of API parameters do not get auto-completed as cloudmonkey isn't able to deduce the probable values for those parameters based on the list APIs heuristics. A lot of these parameters are enums on CloudStack end and by finding a way to expose these and consume them on cloudmonkey side, we could improve the usability of the CLI greatly.

Benefits to CloudStack

• Improved end user experience when using CLI
• Reduce incorrect inputs

Deliverables

• Expose enums and all other relevant information that can be used to enhance auto-completion of parameters on CloudStack end -
  • May require framework level changes and changes to APIs
• Consume these exposed details on Cloudmonkey end

Dependent projects

https://github.com/apache/cloudstack-cloudmonkey/

Ref CloudStack Issue: https://github.com/apache/cloudstack/issues/10442

Author and Publish New Practical Guides for Apache Grails on https://guides.grails.org (will be moved to grails.apache.org soon)

Background

The Grails Guides provide step-by-step, hands-on tutorials with accompanying GitHub repositories containing initial and complete project states. They cover core topics GORM, testing, security, frontend integrations (Vue.js, React, Angular), Micronaut features, deployment (AWS, Google Cloud, GitHub Actions), and more.

Existing guides are strong in foundational and some advanced areas but have gaps in:

• Modern frontend setups
• Broader cloud deployment
• Current DevOps practices
• Popular plugins/ecosystem updates

Creating 5-10 high-quality, up-to-date guides would directly enhance this key learning resource, making Grails more approachable and demonstrating current best practices without requiring core framework changes.

Project Goals

1. Research & Plan Topics: Select 5-10 high-impact guide topics based on community needs (user list discussions, Slack feedback, gaps identified).
2. Develop Guides: For each:
   • Build a complete, runnable Grails application example.
   • Create initial and complete GitHub repos following the standard template.
   • Write a clear, step-by-step Markdown guide with code snippets, explanations, and best-practice rationale.
3. Test & Polish: Ensure guides work with the latest stable Grails (e.g., 7.x or 8.x series), include tests where relevant, and follow accessibility/Asciidoc formatting standards.
4. Submit & Integrate: Open PRs to publish guides update any related docs or grails.org links.
5. Optional Stretch Goals: Add video walkthroughs (if comfortable), create a "What's New in Recent Guides" summary blog post, or contribute minor improvements to existing guides.

Suggested Guide Topics (prioritize with mentor input):

• Building Modern Full-Stack Apps with Grails + React/Vite (or Vue/Vite) – Update/extend older profiles with current tooling.
• Securing Grails APIs with JWT + OAuth2 (modern patterns, perhaps using Micronaut Security).
• Deploying Grails Apps to the cloud
• Advanced CI/CD
• Performance Tuning
• Using HTMX + Grails for Interactive UIs without Heavy Frontend Frameworks.

Deliverables

• 5-10 new published guides on https://guides.grails.org (each with its own GitHub repo under grails-guides).
• Corresponding initial and complete source code repositories.
• Well-structured Markdown/Asciidoc content with clear sections, screenshots/code blocks, and "Try it Yourself" instructions.
• PRs reviewed and merged by mentors/community.
• A short summary report or blog draft for the Grails blog announcing the new guides.
• Documentation updates if needed (e.g., category additions on the guides index page).

Quantifiable Results for the Apache Community:

• Fresh, relevant content that attracts and retains new developers.
• Reduced support burden on mailing lists/Slack by pointing users to modern tutorials.
• Evergreen educational assets maintained by the community.

Proposed Timeline (12-week program)

• Community Bonding (May 2026): Join Grails Slack/mailing list, review existing guides, discuss topic priorities with mentors, fork/clone template repo, set up local build.
• Weeks 1–2: Finalize 3–5 topics, create initial repos, outline guide structures.
• Weeks 3–6: Implement and document first 2–3 guides (focus on core features, testing).
• Weeks 7–9: Complete remaining guides, add polish (screenshots, edge-case notes), self-review for clarity.
• Weeks 10–11: Submit PRs for review, incorporate feedback, test on latest Grails version.
• Week 12: Final merges, any last tweaks, prepare announcement draft, evaluations.

Required Skills

• Solid understanding of Grails (create-app, domains, controllers, services, GSP/JSON views).
• Experience with Groovy/Java and web basics (REST, security concepts).
• Good technical writing (clear, concise explanations).
• Git/GitHub proficiency (branching, PRs).
• Nice-to-have: Familiarity with Asciidoc/Markdown, frontend tools (Vite, npm), or deployment platforms.

Why This Project?

This is a high-reward contribution that directly improves one of Grails' most visible learning resources. It's flexible, scope can adjust based on progress, and allows the student to master Grails while helping others. Similar documentation-focused GSoC projects have succeeded in many Apache projects.

If Grails is accepted for GSoC 2026, this would be an excellent intermediate project. Interested students should contact the Grails dev mailing list or Slack early to discuss topics and secure a mentor. The community welcomes fresh guides to keep the framework vibrant!

 
Difficulty: Medium
Project size: ~350 hour (large)
Potential mentors:
James Fredley

Summary

Currently a lot of API parameters do not get auto-completed as cloudmonkey isn't able to deduce the probable values for those parameters based on the list APIs heuristics. A lot of these parameters are enums on CloudStack end and by finding a way to expose these and consume them on cloudmonkey side, we could improve the usability of the CLI greatly.

Benefits to CloudStack

• Improved end user experience when using CLI
• Reduce incorrect inputs

Deliverables

• Expose enums and all other relevant information that can be used to enhance auto-completion of parameters on CloudStack end -
  • May require framework level changes and changes to APIs
• Consume these exposed details on Cloudmonkey end

Dependent projects

https://github.com/apache/cloudstack-cloudmonkey/

Ref CloudStack Issue: https://github.com/apache/cloudstack/issues/10442

Description:
Apache Fory currently has no Ruby runtime, so Ruby services cannot participate in Fory xlang object exchange. This project implements Ruby xlang serialization with full wire compatibility to existing language runtimes, following the xlang specifications and issue #3379.

Primary references:
1. docs/specification/xlang_serialization_spec.md
2. docs/specification/xlang_implementation_guide.md
3. https://github.com/apache/fory/issues/3379

Scope:
1. Implement xlang binary format in Ruby runtime.
2. Support schema-consistent mode and compatible mode with meta share and TypeDef.
3. Implement registration model for numeric and named user types.
4. Implement deterministic struct serialization rules required by spec.
5. Implement reference tracking and reference flags behavior exactly per protocol.
6. Implement meta string encoding and dedup semantics needed by named types and TypeDef.
7. Provide cross-language interoperability with Java in both encode and decode directions.

Expected outcomes:
1. Ruby runtime package under ruby/ with serializer and deserializer for xlang protocol.
2. Public API centered on Fory entry point with configuration and registration APIs.
3. Core runtime modules for buffer, type resolver, ref resolver, meta string, TypeDef context, and field skipper.
4. Serializer coverage for primitives, temporal types, list, set, map, arrays, structs, and unions.
5. Struct DSL and schema metadata model for deterministic field ordering and stable schema behavior.
6. Compatibility handling for unknown fields and unknown union alternatives via safe skip logic.
7. Documentation for Ruby API usage, registration, schema evolution behavior, and constraints.

Protocol requirements:
1. Little-endian encoding for all multi-byte values.
2. Correct xlang header bitmap handling for null, xlang, and oob flags.
3. Exact reference flags and sequential reference ID assignment.
4. Correct type ID encoding and user type ID handling.
5. Correct namespace and type name metadata behavior for named types.
6. Deterministic struct field ordering exactly aligned with spec.
7. Meta string encoding and per-stream dedup behavior aligned with spec.

Implementation phases:
1. Phase 0: Ruby project skeleton, CI bootstrap, minimal smoke serialization path.
2. Phase 1: Buffer, varint and zigzag utilities, header handling, reference resolver core.
3. Phase 2: Primitive and temporal type support.
4. Phase 3: Collections and arrays support.
5. Phase 4: Type registry and schema-consistent struct serialization.
6. Phase 5: Meta string encoding and dedup.
7. Phase 6: Compatible mode and shared TypeDef.
8. Phase 7: Union and extension type support.
9. Phase 8: Performance hardening and allocation reduction.

Testing and CI requirements:
1. Add Ruby unit tests for protocol primitives, headers, references, and error handling.
2. Add golden vector tests for primitives, string encodings, list/set/map headers, TypeDef, and unions.
3. Add bidirectional interoperability tests:
   - Ruby write to Java read.
   - Java write to Ruby read.
4. Add compatibility tests for schema evolution in compatible mode, including add/remove/reorder and unknown field skipping.
5. Add tests for shared references, circular references, and ref tracking disabled behavior.
6. Add negative tests for invalid varint, unknown type ID, truncated payload, and malformed TypeDef.
7. Integrate Ruby lint and all Ruby xlang tests into CI so regressions fail CI automatically.

Non-goals for initial delivery:
1. Ruby-native non-xlang serialization format.
2. Decimal support.
3. Advanced runtime code generation in first iteration.

Performance expectations:
1. Keep hot serialization and deserialization paths allocation-conscious.
2. Add fast paths for homogeneous collections where safe.
3. Preserve protocol correctness while improving throughput and reducing allocations.

Skills:
Ruby, binary protocol implementation, serialization internals, cross-language compatibility testing, CI integration, performance optimization.

Difficulty:
Hard.

Project size:
Preferred 350 hours.

Potential mentors:
Chaokun Yang, Weipeng Wang.

Source links:
https://github.com/apache/fory/issues/3379
https://github.com/apache/fory/blob/main/docs/specification/xlang_serialization_spec.md
https://github.com/apache/fory/blob/main/docs/specification/xlang_implementation_guide.md
https://github.com/apache/fory/tree/main/rust
https://github.com/apache/fory/tree/main/java

Author and Publish New Practical Guides for Apache Grails on https://guides.grails.org (will be moved to grails.apache.org soon)

Background

The Grails Guides provide step-by-step, hands-on tutorials with accompanying GitHub repositories containing initial and complete project states. They cover core topics GORM, testing, security, frontend integrations (Vue.js, React, Angular), Micronaut features, deployment (AWS, Google Cloud, GitHub Actions), and more.

Existing guides are strong in foundational and some advanced areas but have gaps in:

• Modern frontend setups
• Broader cloud deployment
• Current DevOps practices
• Popular plugins/ecosystem updates

Creating 5-10 high-quality, up-to-date guides would directly enhance this key learning resource, making Grails more approachable and demonstrating current best practices without requiring core framework changes.

Project Goals

1. Research & Plan Topics: Select 5-10 high-impact guide topics based on community needs (user list discussions, Slack feedback, gaps identified).
2. Develop Guides: For each:
   • Build a complete, runnable Grails application example.
   • Create initial and complete GitHub repos following the standard template.
   • Write a clear, step-by-step Markdown guide with code snippets, explanations, and best-practice rationale.
3. Test & Polish: Ensure guides work with the latest stable Grails (e.g., 7.x or 8.x series), include tests where relevant, and follow accessibility/Asciidoc formatting standards.
4. Submit & Integrate: Open PRs to publish guides update any related docs or grails.org links.
5. Optional Stretch Goals: Add video walkthroughs (if comfortable), create a "What's New in Recent Guides" summary blog post, or contribute minor improvements to existing guides.

Suggested Guide Topics (prioritize with mentor input):

• Building Modern Full-Stack Apps with Grails + React/Vite (or Vue/Vite) – Update/extend older profiles with current tooling.
• Securing Grails APIs with JWT + OAuth2 (modern patterns, perhaps using Micronaut Security).
• Deploying Grails Apps to the cloud
• Advanced CI/CD
• Performance Tuning
• Using HTMX + Grails for Interactive UIs without Heavy Frontend Frameworks.

Deliverables

• 5-10 new published guides on https://guides.grails.org (each with its own GitHub repo under grails-guides).
• Corresponding initial and complete source code repositories.
• Well-structured Markdown/Asciidoc content with clear sections, screenshots/code blocks, and "Try it Yourself" instructions.
• PRs reviewed and merged by mentors/community.
• A short summary report or blog draft for the Grails blog announcing the new guides.
• Documentation updates if needed (e.g., category additions on the guides index page).

Quantifiable Results for the Apache Community:

• Fresh, relevant content that attracts and retains new developers.
• Reduced support burden on mailing lists/Slack by pointing users to modern tutorials.
• Evergreen educational assets maintained by the community.

Proposed Timeline (12-week program)

• Community Bonding (May 2026): Join Grails Slack/mailing list, review existing guides, discuss topic priorities with mentors, fork/clone template repo, set up local build.
• Weeks 1–2: Finalize 3–5 topics, create initial repos, outline guide structures.
• Weeks 3–6: Implement and document first 2–3 guides (focus on core features, testing).
• Weeks 7–9: Complete remaining guides, add polish (screenshots, edge-case notes), self-review for clarity.
• Weeks 10–11: Submit PRs for review, incorporate feedback, test on latest Grails version.
• Week 12: Final merges, any last tweaks, prepare announcement draft, evaluations.

Required Skills

• Solid understanding of Grails (create-app, domains, controllers, services, GSP/JSON views).
• Experience with Groovy/Java and web basics (REST, security concepts).
• Good technical writing (clear, concise explanations).
• Git/GitHub proficiency (branching, PRs).
• Nice-to-have: Familiarity with Asciidoc/Markdown, frontend tools (Vite, npm), or deployment platforms.

Why This Project?

This is a high-reward contribution that directly improves one of Grails' most visible learning resources. It's flexible, scope can adjust based on progress, and allows the student to master Grails while helping others. Similar documentation-focused GSoC projects have succeeded in many Apache projects.

If Grails is accepted for GSoC 2026, this would be an excellent intermediate project. Interested students should contact the Grails dev mailing list or Slack early to discuss topics and secure a mentor. The community welcomes fresh guides to keep the framework vibrant!

 
Difficulty: Medium
Project size: ~350 hour (large)
Potential mentors:
James Fredley

Description:
Apache Fory currently has no Ruby runtime, so Ruby services cannot participate in Fory xlang object exchange. This project implements Ruby xlang serialization with full wire compatibility to existing language runtimes, following the xlang specifications and issue #3379.

Primary references:
1. docs/specification/xlang_serialization_spec.md
2. docs/specification/xlang_implementation_guide.md
3. https://github.com/apache/fory/issues/3379

Scope:
1. Implement xlang binary format in Ruby runtime.
2. Support schema-consistent mode and compatible mode with meta share and TypeDef.
3. Implement registration model for numeric and named user types.
4. Implement deterministic struct serialization rules required by spec.
5. Implement reference tracking and reference flags behavior exactly per protocol.
6. Implement meta string encoding and dedup semantics needed by named types and TypeDef.
7. Provide cross-language interoperability with Java in both encode and decode directions.

Expected outcomes:
1. Ruby runtime package under ruby/ with serializer and deserializer for xlang protocol.
2. Public API centered on Fory entry point with configuration and registration APIs.
3. Core runtime modules for buffer, type resolver, ref resolver, meta string, TypeDef context, and field skipper.
4. Serializer coverage for primitives, temporal types, list, set, map, arrays, structs, and unions.
5. Struct DSL and schema metadata model for deterministic field ordering and stable schema behavior.
6. Compatibility handling for unknown fields and unknown union alternatives via safe skip logic.
7. Documentation for Ruby API usage, registration, schema evolution behavior, and constraints.

Protocol requirements:
1. Little-endian encoding for all multi-byte values.
2. Correct xlang header bitmap handling for null, xlang, and oob flags.
3. Exact reference flags and sequential reference ID assignment.
4. Correct type ID encoding and user type ID handling.
5. Correct namespace and type name metadata behavior for named types.
6. Deterministic struct field ordering exactly aligned with spec.
7. Meta string encoding and per-stream dedup behavior aligned with spec.

Implementation phases:
1. Phase 0: Ruby project skeleton, CI bootstrap, minimal smoke serialization path.
2. Phase 1: Buffer, varint and zigzag utilities, header handling, reference resolver core.
3. Phase 2: Primitive and temporal type support.
4. Phase 3: Collections and arrays support.
5. Phase 4: Type registry and schema-consistent struct serialization.
6. Phase 5: Meta string encoding and dedup.
7. Phase 6: Compatible mode and shared TypeDef.
8. Phase 7: Union and extension type support.
9. Phase 8: Performance hardening and allocation reduction.

Testing and CI requirements:
1. Add Ruby unit tests for protocol primitives, headers, references, and error handling.
2. Add golden vector tests for primitives, string encodings, list/set/map headers, TypeDef, and unions.
3. Add bidirectional interoperability tests:
   - Ruby write to Java read.
   - Java write to Ruby read.
4. Add compatibility tests for schema evolution in compatible mode, including add/remove/reorder and unknown field skipping.
5. Add tests for shared references, circular references, and ref tracking disabled behavior.
6. Add negative tests for invalid varint, unknown type ID, truncated payload, and malformed TypeDef.
7. Integrate Ruby lint and all Ruby xlang tests into CI so regressions fail CI automatically.

Non-goals for initial delivery:
1. Ruby-native non-xlang serialization format.
2. Decimal support.
3. Advanced runtime code generation in first iteration.

Performance expectations:
1. Keep hot serialization and deserialization paths allocation-conscious.
2. Add fast paths for homogeneous collections where safe.
3. Preserve protocol correctness while improving throughput and reducing allocations.

Skills:
Ruby, binary protocol implementation, serialization internals, cross-language compatibility testing, CI integration, performance optimization.

Difficulty:
Hard.

Project size:
Preferred 350 hours.

Potential mentors:
Chaokun Yang, Weipeng Wang.

Source links:
https://github.com/apache/fory/issues/3379
https://github.com/apache/fory/blob/main/docs/specification/xlang_serialization_spec.md
https://github.com/apache/fory/blob/main/docs/specification/xlang_implementation_guide.md
https://github.com/apache/fory/tree/main/rust
https://github.com/apache/fory/tree/main/java

already defines a cross-language row format and has standard row format implementations in Java, C++, and Python. This task adds standard row format support for Go, Swift, Dart, and JavaScript based on docs/specification/row_format_spec.md.

The implementation must follow the standard row format rules exactly, including 8-byte alignment, null bitmap behavior, fixed 8-byte field slots, relative offset plus size encoding for variable-width fields, and deterministic padding behavior.

Compact row format is explicitly out of scope for this task.

Primary specification:
docs/specification/row_format_spec.md

Expected outcomes:
1. Add standard row format read and write support in Go runtime.
2. Add standard row format read and write support in Swift runtime.
3. Add standard row format read and write support in Dart runtime.
4. Add standard row format read and write support in JavaScript runtime.
5. Implement standard row layout support for rows, arrays, maps, and nested structs according to the spec.
6. Ensure random field access without full object deserialization for supported field types.
7. Add clear API entry points for encoding typed data to row format and decoding or field-accessing from row format.
8. Update language guides and developer docs for row format usage and constraints.

Required compatibility and test scope:
1. Add per-language unit tests for null bitmap handling, fixed-width fields, variable-width offset and size encoding, alignment, and padding.
2. Add deterministic binary tests to verify encoded bytes for representative schemas.
3. Add cross-language compatibility tests against existing standard row format implementations, with Java as required reference endpoint.
4. Add interoperability tests for each new language reading rows produced by Java and writing rows that Java can read.
5. Add map and nested struct compatibility cases, not only primitive fields.
6. Add CI coverage for all new tests so regressions fail CI automatically.

Non-goals:
1. Compact row format implementation.
2. Protocol or wire format changes outside current standard row format specification.
3. Unrelated serialization runtime features not required for standard row format support.

Skills:
Go, Swift, Dart, JavaScript or TypeScript, binary format implementation, compiler or runtime internals, cross-language compatibility testing, performance-focused engineering.

Difficulty:
Hard.

Project size:
Preferred 350 hours.

Potential mentors:
Chaokun Yang, Weipeng Wang.

Source links:
https://github.com/apache/fory/tree/main/docs/specification
https://github.com/apache/fory/blob/main/docs/specification/row_format_spec.md
https://github.com/apache/fory/tree/main/go
https://github.com/apache/fory/tree/main/swift
https://github.com/apache/fory/tree/main/dart
https://github.com/apache/fory/tree/main/javascript

Description:
Apache Fory currently lacks a Lua runtime for xlang serialization. This project will implement Lua xlang serialization with protocol-correct wire compatibility against existing Fory runtimes.

Primary references:
1. docs/specification/xlang_serialization_spec.md
2. docs/specification/xlang_implementation_guide.md

Scope:
1. Implement Lua xlang encoder and decoder using little-endian binary format.
2. Implement type registry for numeric and named user types.
3. Implement serialization and deserialization for struct, enum, and union.
4. Support schema-consistent mode and compatible mode with meta share and TypeDef.
5. Implement metatable restoration for registered struct-like objects during deserialization.
6. Deliver cross-language interoperability with existing runtimes, with Java and Python as mandatory interoperability targets.

Expected outcomes:
1. New Lua module with public API:
   - Fory.new(config)
   - serialize(value, declared_type)
   - deserialize(bytes, declared_type)
2. Core runtime modules:
   - buffer and varint codecs
   - header handling
   - reference resolver
   - type registry and type metadata
   - meta string and TypeDef handling
   - serializers for primitive, collection, map, enum, struct, and union
   - skip-value support for unknown fields and union alternatives
3. Protocol-correct handling for:
   - header bitmap flags
   - reference flags and reference ID assignment
   - type IDs and user_type_id encoding
   - meta string encoding and dedup
   - list and map headers
   - deterministic struct field ordering
   - union payload encoding
4. Documentation for Lua usage, registration rules, compatible mode behavior, and interoperability constraints.

Implementation phases:
1. Phase 0: project bootstrap and API scaffold.
2. Phase 1: core buffer, little-endian codecs, varints, and header read/write.
3. Phase 2: reference tracking and type meta core.
4. Phase 3: primitive and temporal serializers.
5. Phase 4: collection and map protocol support.
6. Phase 5: meta string and TypeDef support.
7. Phase 6: enum, struct, and union.
8. Phase 7: skip logic, compatibility hardening, malformed-input resilience.
9. Phase 8: performance optimization with pure Lua baseline and optional LuaJIT fast paths.

Testing and CI requirements:
1. Add Lua unit tests for buffer, varint, zigzag, tagged64, header flags, ref resolver, type meta, and TypeDef.
2. Add cross-language compatibility tests:
   - Lua serialize -> Java deserialize.
   - Java serialize -> Lua deserialize.
   - Lua serialize -> Python deserialize.
   - Python serialize -> Lua deserialize.
3. Include protocol-critical cases:
   - primitives and boundary values
   - UTF8, LATIN1, and UTF16 string payloads
   - list, set, and map header combinations
   - schema-consistent and compatible struct behavior
   - known and unknown union cases
   - shared and circular references
4. Add regression fixtures for deterministic protocol-critical payloads.
5. Add negative tests for malformed varint, unknown type ID, truncated payload, and malformed TypeDef.
6. Integrate Lua lint and all Lua xlang tests into CI so regressions fail automatically.

Non-goals for initial delivery:
1. Row format implementation.
2. Decimal support.
3. Native code generation or JIT-only dependency as a requirement.

Performance requirements:
1. Keep pure Lua path as canonical and fully compliant.
2. Avoid unnecessary allocations in hot encode and decode paths.
3. Ensure optimizations do not change protocol behavior.

Skills:
Lua 5.4 or 5.3, binary protocol implementation, serialization internals, cross-language compatibility testing, CI integration, performance optimization

Description:
Apache Fory already defines a cross-language row format and has standard row format implementations in Java, C++, and Python. This task adds standard row format support for Go, Swift, Dart, and JavaScript based on docs/specification/row_format_spec.md.

The implementation must follow the standard row format rules exactly, including 8-byte alignment, null bitmap behavior, fixed 8-byte field slots, relative offset plus size encoding for variable-width fields, and deterministic padding behavior.

Compact row format is explicitly out of scope for this task.

Primary specification:
docs/specification/row_format_spec.md

Expected outcomes:
1. Add standard row format read and write support in Go runtime.
2. Add standard row format read and write support in Swift runtime.
3. Add standard row format read and write support in Dart runtime.
4. Add standard row format read and write support in JavaScript runtime.
5. Implement standard row layout support for rows, arrays, maps, and nested structs according to the spec.
6. Ensure random field access without full object deserialization for supported field types.
7. Add clear API entry points for encoding typed data to row format and decoding or field-accessing from row format.
8. Update language guides and developer docs for row format usage and constraints.

Required compatibility and test scope:
1. Add per-language unit tests for null bitmap handling, fixed-width fields, variable-width offset and size encoding, alignment, and padding.
2. Add deterministic binary tests to verify encoded bytes for representative schemas.
3. Add cross-language compatibility tests against existing standard row format implementations, with Java as required reference endpoint.
4. Add interoperability tests for each new language reading rows produced by Java and writing rows that Java can read.
5. Add map and nested struct compatibility cases, not only primitive fields.
6. Add CI coverage for all new tests so regressions fail CI automatically.

Non-goals:
1. Compact row format implementation.
2. Protocol or wire format changes outside current standard row format specification.
3. Unrelated serialization runtime features not required for standard row format support.

Skills:
Go, Swift, Dart, JavaScript or TypeScript, binary format implementation, compiler or runtime internals, cross-language compatibility testing, performance-focused engineering.

Difficulty:
Hard.

Project size:
Preferred 350 hours.

Potential mentors:
Chaokun Yang, Weipeng Wang.

Source links:
1. https://github.com/apache/fory/tree/main/docs/specification
issues/3380
2. https://github.com/apache/fory/blob/main/docs/specification/rowxlang_formatserialization_spec.md
3. https://github.com/apache/fory/treeblob/main/go
https:docs/specification/github.com/apache/fory/tree/main/swift
https://github.com/apache/fory/tree/main/dart
https://github.com/apache/fory/tree/main/javascriptxlang_implementation_guide.md

Description:
Apache Fory currently lacks a Lua runtime for xlang serialization. This project will implement Lua xlang serialization with protocol-correct wire compatibility against existing Fory runtimes.

Primary references:
1. docs/specification/xlang_serialization_spec.md
2. docs/specification/xlang_implementation_guide.md

Scope:
1. Implement Lua xlang encoder and decoder using little-endian binary format.
2. Implement type registry for numeric and named user types.
3. Implement serialization and deserialization for struct, enum, and union.
4. Support schema-consistent mode and compatible mode with meta share and TypeDef.
5. Implement metatable restoration for registered struct-like objects during deserialization.
6. Deliver cross-language interoperability with existing runtimes, with Java and Python as mandatory interoperability targets.

Expected outcomes:
1. New Lua module with public API:
   - Fory.new(config)
   - serialize(value, declared_type)
   - deserialize(bytes, declared_type)
2. Core runtime modules:
   - buffer and varint codecs
   - header handling
   - reference resolver
   - type registry and type metadata
   - meta string and TypeDef handling
   - serializers for primitive, collection, map, enum, struct, and union
   - skip-value support for unknown fields and union alternatives
3. Protocol-correct handling for:
   - header bitmap flags
   - reference flags and reference ID assignment
   - type IDs and user_type_id encoding
   - meta string encoding and dedup
   - list and map headers
   - deterministic struct field ordering
   - union payload encoding
4. Documentation for Lua usage, registration rules, compatible mode behavior, and interoperability constraints.

Implementation phases:
1. Phase 0: project bootstrap and API scaffold.
2. Phase 1: core buffer, little-endian codecs, varints, and header read/write.
3. Phase 2: reference tracking and type meta core.
4. Phase 3: primitive and temporal serializers.
5. Phase 4: collection and map protocol support.
6. Phase 5: meta string and TypeDef support.
7. Phase 6: enum, struct, and union.
8. Phase 7: skip logic, compatibility hardening, malformed-input resilience.
9. Phase 8: performance optimization with pure Lua baseline and optional LuaJIT fast paths.

Testing and CI requirements:
1. Add Lua unit tests for buffer, varint, zigzag, tagged64, header flags, ref resolver, type meta, and TypeDef.
2. Add cross-language compatibility tests:
   - Lua serialize -> Java deserialize.
   - Java serialize -> Lua deserialize.
   - Lua serialize -> Python deserialize.
   - Python serialize -> Lua deserialize.
3. Include protocol-critical cases:
   - primitives and boundary values
   - UTF8, LATIN1, and UTF16 string payloads
   - list, set, and map header combinations
   - schema-consistent and compatible struct behavior
   - known and unknown union cases
   - shared and circular references
4. Add regression fixtures for deterministic protocol-critical payloads.
5. Add negative tests for malformed varint, unknown type ID, truncated payload, and malformed TypeDef.
6. Integrate Lua lint and all Lua xlang tests into CI so regressions fail automatically.

Non-goals for initial delivery:
1. Row format implementation.
2. Decimal support.
3. Native code generation or JIT-only dependency as a requirement.

Performance requirements:
1. Keep pure Lua path as canonical and fully compliant.
2. Avoid unnecessary allocations in hot encode and decode paths.
3. Ensure optimizations do not change protocol behavior.

Skills:
Lua 5.4 or 5.3, binary protocol implementation, serialization internals, cross-language compatibility testing, CI integration, performance optimization.

can already generate high-performance Java and Python model code from IDL, but end-to-end Java/Python gRPC integration is not available as a unified workflow.

This project will implement Java and Python gRPC integration in the Fory compiler by generating language-specific service and transport artifacts.
Java output artifacts: *Service.java and *Grpc.java.
Python output artifacts: *_service.py and *_grpc.py.

The implementation must use Fory serialization only, without protobuf runtime payload types. It must follow compiler conventions and keep runtime overhead low.

Expected outcomes:
1. Generate Java and Python gRPC service and binding code from service definitions.
2. Support unary and streaming RPC APIs based on Fory service IR.
3. Generate Fory-based request and response marshalling for both languages.
4. Implement zero-copy decode paths for inbound payloads in both Java and Python, with a safe fallback path when zero-copy cannot be applied.
5. Add golden code generation tests for output file names and key method signatures in both Java and Python generators.
6. Provide runnable Java and Python gRPC examples using generated stubs and Fory codec.
7. Update compiler documentation for Java and Python gRPC code generation usage and constraints.

Required cross-language gRPC tests between Java and Python services:
1. Add integration tests for Java server with Python client.
2. Add integration tests for Python server with Java client.
3. Cover request and response round-trip correctness using Fory-serialized payloads.
4. Include unary RPC coverage as required. Include streaming coverage when corresponding generated streaming APIs are in scope.
5. Validate compatibility for normal cases and key error paths, including decode errors and type mismatch.
6. Add coverage for zero-copy decode paths and fallback behavior in both Java and Python integrations.

CI end-to-end test requirements:
1. Add Java and Python gRPC end-to-end interoperability tests into CI.
2. CI must execute both directions: Java server to Python client, and Python server to Java client.
3. CI must fail on serialization compatibility regressions.
4. CI should run deterministic test cases with stable assertions for payload correctness and error handling behavior.

Skills:
Java, Python, gRPC Java, grpcio, compiler and code generation, serialization internals, testing, performance optimization.

Difficulty:
Medium to Hard.

Project size:
Preferred 350 hours.

Potential mentors:
Chaokun Yang, Weipeng Wang.

Source links:
https://github.com/apache/fory/issues/3272
https://github.com/apache/fory/issues/3273
https://fory.apache.org/docs/next/compiler/compiler_guide
https://github.com/apache/fory/tree/main/compiler
https://github.com/apache/fory/tree/main/java
https://github.com/apache/fory/tree/main/python
https://fory.apache.org/docs/next/guide/java/
https://fory.apache.org/docs/guide/python/

Description:
Apache Fory can generate high-performance C++ and Rust model code from IDL, but it does not yet provide end-to-end gRPC service binding generation for both languages as one aligned workflow.

This project will add C++ and Rust gRPC code generation in the Fory compiler using Fory serialization instead of protobuf runtime payload types.

C++ generated outputs:

• service.h for service API abstractions.
• service.grpc.h for gRPC declarations.
• service.grpc.cc for gRPC implementations.

Rust generated outputs:

• service.rs for service API traits/modules.
• service_grpc.rs for tonic server/client transport bindings.

The implementation should follow Fory compiler conventions and prioritize performance-first, low-overhead runtime behavior.

Expected outcomes:
1. Parse service IR and generate C++ and Rust gRPC outputs from service definitions.
2. Support unary and streaming RPC method generation in both language targets.
3. Generate clear separation between language-level API abstractions and transport bindings.
4. Generate C++ abstract service interfaces and client stubs compatible with gRPC C++.
5. Generate Rust tonic-compatible async server and client wrappers.
6. Implement Fory-based request and response serialization hooks for both C++ and Rust generated bindings.
7. Implement zero-copy deserialization buffer support for inbound gRPC payloads in both languages, with safe fallback when zero-copy cannot be applied.
8. Add golden code generation tests for generated file names and key method signatures in both targets.
9. Add runtime tests for codec round-trip behavior, error handling, and fallback behavior.
10. Add interoperability tests for C++ and Rust generated services, including C++ server with Rust client and Rust server with C++ client.
11. Provide runnable C++ and Rust server/client examples using generated bindings and Fory codec.
12. Update compiler and language documentation for C++/Rust gRPC code generation usage and constraints.

CI requirements:
1. Add C++ and Rust gRPC code generation tests to CI.
2. Add C++ and Rust runtime tests for generated codec and service bindings to CI.
3. CI must fail on generated API signature regressions and serialization compatibility regressions.

Skills:
C++ 17, Rust, gRPC, tonic, compiler and code generation, serialization internals, async Rust, testing, performance optimization.

Difficulty:
Medium to Difficulty:
Hard.

Project size:
Preferred 350 hours.

Potential mentors:
Chaokun Yang, Weipeng Wang.

Source links:
1. https://github.com/apache/fory/issues/3276
https://github.com/apache/fory/issues/3380
2. 3275
https://fory.apache.org/docs/next/compiler/compiler_guide
https://github.com/apache/fory/blobtree/main/docscompiler
https:/specification/xlang_serialization_spec.md
3. github.com/apache/fory/tree/main/cpp
https://github.com/apache/fory/blobtree/main/docs/specification/xlang_implementation_guide.md

Apache Fory has a mature compiler pipeline for FDL, Protocol Buffers, and FlatBuffers frontends, plus code generators for Java, Python, Go, Rust, and C++. The compiler also already includes service IR parsing and a `--grpc` generation path, but Swift code generation is not yet supported.

This project adds end-to-end Swift support in two layers:

1. Swift schema and model code generation from Fory IR.
2. Swift gRPC generation from service definitions, including transport bindings and a Fory-backed codec.

The implementation should follow existing compiler conventions and prioritize low-overhead, allocation-conscious runtime behavior.

Problem Statement
The repository already contains a Swift runtime (`swift/Sources/Fory`) but lacks compiler-generated Swift model code and Swift gRPC bindings from IDL files. This creates a gap:

• Swift users cannot use `foryc` to generate model types from `.fdl`, `.proto`, or `.fbs`.
• Service definitions parsed into compiler IR cannot yet target Swift transport code.
• There is no official Fory codec integration for grpc-swift.

Why This Project Matters

• Completes the Swift developer workflow: IDL -> generated models -> generated service APIs -> runnable gRPC client and server.
• Reuses existing multi-frontend service parsing support in compiler IR.
• Aligns Swift with other language targets and improves cross-language consistency.
• Enables high-performance Swift service communication using Fory serialization semantics.

Expected Outcomes

• Add Swift as a first-class compiler target (`{}lang swift`, `{-}-swift_out`).
• Generate Swift model code from schema definitions (messages, enums, unions, nested types).
• Generate `service_grpc.swift` from service definitions.
• Generate grpc-swift compatible async server and client wrappers.
• Implement a custom grpc-swift codec backed by Fory serialization and deserialization.
• Implement inbound zero-copy decode support with a safe copy fallback path.
• Add golden-style codegen tests for filenames and key generated signatures.
• Add cross-frontend parity tests for FDL, proto, and fbs service definitions.
• Provide runnable Swift server and client example(s) using generated code and codec.
• Document compiler usage, constraints, and integration steps.

Detailed Scope
1) Compiler and CLI Integration

• Add `SwiftGenerator` under `compiler/fory_compiler/generators/`.
• Register generator in `compiler/fory_compiler/generators/{}init{}.py`.
• Extend CLI output mapping and options to support `--swift_out`.
• Ensure `--lang swift` works with existing recursive import compilation flow.

2) Swift Model Code Generation
Generate Swift for:

• Enums
• Messages
• Unions
• Nested types
• Type registration helper APIs

Requirements:

• Follow Fory type ID behavior (explicit IDs, auto IDs, namespace/name registration fallback).
• Match existing cross-language semantics where applicable.
• Integrate with existing Swift runtime abstractions (`Serializer`, type resolver, registration APIs).

3) Swift Service and gRPC Code Generation
For each schema service:

• Generate `service.swift` containing service protocol and method shape declarations.
• Generate `service_grpc.swift` containing grpc-swift server and client transport bindings.

Required RPC support:

• Unary
• Client streaming
• Server streaming
• Bidirectional streaming

4) Fory Codec for grpc-swift

• Implement codec encode and decode using Fory Swift runtime.
• Ensure request and response types map correctly to generated Swift types.
• Provide clear error mapping for decode and type mismatch failures.

5) Zero-Copy Decode and Fallback

• Add a zero-copy-friendly decode path for inbound payload handling when safe ownership and lifecycle constraints are satisfied.
• Add a fallback path that copies payload bytes when zero-copy cannot be safely applied.
• Ensure behavior is deterministic and memory-safe.

6) Tests
Compiler tests:

• Add codegen tests validating generated Swift file names and key signatures.
• Add service generation tests for all RPC modes.
• Add cross-frontend equivalence tests for FDL/proto/fbs service definitions.

Swift runtime and integration tests:

• Codec round-trip tests.
• Error-path tests (invalid payload, type mismatch, unsupported mode).
• Zero-copy path and fallback path coverage.

7) Examples and Documentation

• Add runnable Swift gRPC server/client example using generated files.
• Update `docs/compiler/compiler-guide.md` for Swift codegen options and usage.
• Update `docs/compiler/generated-code.md` with Swift output layout and generated API shape.
• Add concise Swift integration documentation for grpc-swift + Fory codec.

Performance and Quality Requirements

• Keep allocation count low on encode and decode paths.
• Avoid unnecessary data copies in transport integration.
• Keep generated code predictable and stable for golden-style testing.
• Preserve compiler behavior for existing languages and frontends.

Milestones (Recommended)
1. Community Bonding

• Finalize generated API naming and file layout.
• Confirm Swift option strategy and dependency constraints.
• Agree on test matrix and acceptance checklist.

2. Phase 1

• Implement Swift generator base and CLI wiring.
• Generate core model types and registration helpers.
• Add baseline model codegen tests.

3. Phase 2

• Implement service generation (`service.swift`, `service_grpc.swift`).
• Support unary and all streaming RPC method shapes.
• Add service signature and transport generation tests.

4. Phase 3

• Implement and validate Fory grpc-swift codec.
• Implement zero-copy decode path and fallback path.
• Add integration example and end-to-end tests.

Finalization

• Documentation updates.
• Stability pass and cleanup.
• Final validation across compiler and Swift test suites.

Acceptance Criteria
1. `foryc` supports Swift generation through `{}lang swift` and `{-}-swift_out`.
2. Swift model code compiles and integrates with Fory Swift runtime.
3. Service generation outputs `service.swift` and `service_grpc.swift` with correct signatures.
4. Unary, client-streaming, server-streaming, and bidi-streaming methods are correctly generated.
5. Fory-backed grpc-swift codec works for request and response round-trip.
6. Zero-copy decode path exists with tested fallback behavior.
7. Added tests pass and no regressions are introduced in existing compiler suites.
8. Documentation and runnable Swift example are complete and usable.

Skills Required

• Swift
• grpc-swift
• Compiler and code generation
• Serialization internals
• Async and streaming APIs
• Testing and performance profiling

Difficulty
Hard

Project Size
350 hours

Potential Mentors

• Chaokun Yang
• Weipeng Wang

Source Links

• https://github.com/apache/fory/issues/3370
• https://fory.apache.org/docs/next/compiler/compiler_guide
• https://github.com/apache/fory/tree/main/compiler
• https://github.com/apache/fory/tree/main/compiler/fory_compiler
• https://github.com/apache/fory/tree/main/compiler/fory_compiler/tests
• https://github.com/apache/fory/tree/main/swift
• https://fory.apache.org/docs/guide/rust/
• https://github.com/grpc/grpc-swift

rust
https://fory.apache.org/docs/guide/cpp/
https://fory.apache.org/docs/guide/rust/

Description:
Apache Fory can generate high-performance model code for Go and JavaScript/TypeScript from IDL, but end-to-end gRPC service binding generation across these two ecosystems is not yet complete as a unified workflow.
This project will add Go and JavaScript/TypeScript gRPC code generation to the Fory compiler using Fory serialization instead of protobuf runtime payload types.
The implementation should follow Fory compiler conventions, remain dependency-light in runtime layers, and prioritize low-overhead, performance-first behavior.

Potential Outcomes:

1. Parse service IR and generate Go and JavaScript/TypeScript gRPC outputs for unary and streaming methods.
2. Generate Go outputs `_service.go` and `_grpc.go` with ServiceDesc, server interfaces, and client wrappers compatible with grpc-go.
3. Generate JavaScript/TypeScript service interface and gRPC binding outputs compatible with @grpc/grpc-js and existing JS/TS generator layout conventions.
4. Wire request/response payload handling through generated Fory serializer and deserializer functions in both targets.
5. Implement zero-copy deserialization buffer support for inbound gRPC payloads in both Go and JavaScript runtimes, with safe fallback paths when zero-copy cannot be applied.
6. Coordinate with JS/TS type generation so emitted message, enum, and union types are directly usable by generated gRPC stubs.
7. Add golden codegen tests for generated file names and key signatures for both language targets.
8. Add end-to-end interoperability tests between generated Go and JavaScript services, including Go server with JS client and JS server with Go client.
9. Add CI coverage for codegen tests, runtime codec tests, and Go<->JavaScript gRPC interoperability tests.
10. Provide runnable Go and JavaScript/TypeScript server-client examples using generated bindings and Fory codec.
11. Update compiler documentation for Go and JavaScript/TypeScript gRPC code generation usage and constraints.

Skills:
Go, JavaScript/TypeScript, Node.js, gRPC (grpc-go and @grpc/grpc-js), compiler/code generation, serialization internals, testing, performance optimization.

Difficulty:
Medium to Hard
 
Project size:
350 hours

Potential mentors:
Chaokun Yang, Weipeng Wang

Source links:

1. https://github.com/apache/fory/issues/3274
2. https://github.com/apache/fory/issues/3278
3. https://github.com/apache/fory/issues/3280
4. https://fory.apache.org/docs/next/compiler/compiler_guide
5. https://github.com/apache/fory/tree/main/compiler
6. https://github.com/apache/fory/tree/main/go
7. https://github.com/apache/fory/tree/main/javascript
8. https://fory.apache.org/docs/guide/go/

Description

Apache Fory does not yet generate Dart gRPC service bindings.

This project will add Dart gRPC code generation to the Fory compiler. For each service definition, the compiler should generate Dart service interfaces and gRPC transport bindings that follow the existing Dart generator layout and use a Fory codec instead of protobuf runtime payload types.

The implementation must keep the Fory runtime free of gRPC dependencies. Any required gRPC glue should be emitted as generated helper code. Runtime behavior should remain low-overhead and allocation-conscious.

Potential Outcomes

• Generate Dart service interface and gRPC binding outputs from service definitions, aligned with current Dart generator conventions.
• Generate Dart gRPC server and client stubs for unary and streaming RPCs using Dart gRPC APIs.
• Wire request/response handling through generated Fory serializer and deserializer functions.
• Implement zero-copy deserialization buffer support for inbound gRPC payloads, with a safe fallback path when zero-copy cannot be applied.
• Coordinate with Dart type generation so emitted message, enum, and union types are directly usable by generated gRPC stubs.
• Add golden codegen tests for generated file names and key signatures.
• Provide a runnable Dart server/client example using generated bindings and the Fory codec.
• Update compiler documentation for Dart gRPC code generation usage and constraints.

Skills：Dart, gRPC (`grpc`), compiler/code generation, serialization internals, async programming, testing, performance optimization.

Difficulty： Medium
Project size：175 hours
Potential mentors：Chaokun Yang, Weipeng Wang
Source links：

• https://github.com/apache/fory/issues/3279
• https://github.com/apache/fory/issues/3281
• https://fory.apache.org/docs/next/compiler/compiler_guide
• https://github.com/apache/fory/tree/main/compiler
• https://github.com/apache/fory/tree/main/dart
• https://github.com/apache/fory/blob/main/dart/README.md
• https://github.com/apache/fory/tree/main/dart/packages/fory

Apache Fory has a mature compiler pipeline for FDL, Protocol Buffers, and FlatBuffers frontends, plus code generators for Java, Python, Go, Rust, and C++. The compiler also already includes service IR parsing and a `--grpc` generation path, but Swift code generation is not yet supported.

This project adds end-to-end Swift support in two layers:

1. Swift schema and model code generation from Fory IR.
2. Swift gRPC generation from service definitions, including transport bindings and a Fory-backed codec.

The implementation should follow existing compiler conventions and prioritize low-overhead, allocation-conscious runtime behavior.

Problem Statement
The repository already contains a Swift runtime (`swift/Sources/Fory`) but lacks compiler-generated Swift model code and Swift gRPC bindings from IDL files. This creates a gap:

• Swift users cannot use `foryc` to generate model types from `.fdl`, `.proto`, or `.fbs`.
• Service definitions parsed into compiler IR cannot yet target Swift transport code.
• There is no official Fory codec integration for grpc-swift.

Why This Project Matters

• Completes the Swift developer workflow: IDL -> generated models -> generated service APIs -> runnable gRPC client and server.
• Reuses existing multi-frontend service parsing support in compiler IR.
• Aligns Swift with other language targets and improves cross-language consistency.
• Enables high-performance Swift service communication using Fory serialization semantics.

Expected Outcomes

• Add Swift as a first-class compiler target (`{}lang swift`, `{-}-swift_out`).
• Generate Swift model code from schema definitions (messages, enums, unions, nested types).
• Generate `service_grpc.swift` from service definitions.
• Generate grpc-swift compatible async server and client wrappers.
• Implement a custom grpc-swift codec backed by Fory serialization and deserialization.
• Implement inbound zero-copy decode support with a safe copy fallback path.
• Add golden-style codegen tests for filenames and key generated signatures.
• Add cross-frontend parity tests for FDL, proto, and fbs service definitions.
• Provide runnable Swift server and client example(s) using generated code and codec.
• Document compiler usage, constraints, and integration steps.

Detailed Scope
1) Compiler and CLI Integration

• Add `SwiftGenerator` under `compiler/fory_compiler/generators/`.
• Register generator in `compiler/fory_compiler/generators/{}init{}.py`.
• Extend CLI output mapping and options to support `--swift_out`.
• Ensure `--lang swift` works with existing recursive import compilation flow.

2) Swift Model Code Generation
Generate Swift for:

• Enums
• Messages
• Unions
• Nested types
• Type registration helper APIs

3) Swift Service and gRPC Code Generation
For each schema service:

• Generate `service.swift` containing service protocol and method shape declarations.
• Generate `service_grpc.swift` containing grpc-swift server and client transport bindings.

Required RPC support:

• Unary
• Client streaming
• Server streaming
• Bidirectional streaming

4) Fory Codec for grpc-swift

• Implement codec encode and decode using Fory Swift runtime.
• Ensure request and response types map correctly to generated Swift types.
• Provide clear error mapping for decode and type mismatch failures.

5) Zero-Copy Decode and Fallback

• Add a zero-copy-friendly decode path for inbound payload handling when safe ownership and lifecycle constraints are satisfied.
• Add a fallback path that copies payload bytes when zero-copy cannot be safely applied.
• Ensure behavior is deterministic and memory-safe.

6) Tests

• Add codegen tests validating generated Swift file names and key signatures.
• Add service generation tests for all RPC modes.
• Add cross-frontend equivalence tests for FDL/proto/fbs service definitions.
• Codec round-trip tests.
• Error-path tests (invalid payload, type mismatch, unsupported mode).
• Zero-copy path and fallback path coverage.

7) Examples and Documentation

• Add runnable Swift gRPC server/client example using generated files.
• Update `docs/compiler/compiler-guide.md` for Swift codegen options and usage.
• Update `docs/compiler/generated-code.md` with Swift output layout and generated API shape.
• Add concise Swift integration documentation for grpc-swift + Fory codec.

Performance and Quality Requirements

• Keep allocation count low on encode and decode paths.
• Avoid unnecessary data copies in transport integration.
• Keep generated code predictable and stable for golden-style testing.
• Preserve compiler behavior for existing languages and frontends.

Acceptance Criteria
1. `foryc` supports Swift generation through `{}lang swift` and `{-}-swift_out`.
2. Swift model code compiles and integrates with Fory Swift runtime.
3. Service generation outputs `service.swift` and `service_grpc.swift` with correct signatures.
4. Unary, client-streaming, server-streaming, and bidi-streaming methods are correctly generated.
5. Fory-backed grpc-swift codec works for request and response round-trip.
6. Zero-copy decode path exists with tested fallback behavior.
7. Added tests pass and no regressions are introduced in existing compiler suites.
8. Documentation and runnable Swift example are complete and usable.

Skills Required

• Swift
• grpc-swift
• Compiler and code generation
• Serialization internals
• Async and streaming APIs
• Testing and performance profiling

Difficulty
Hard

Project Size
350 hours

Potential Mentors

• Chaokun Yang
• Weipeng Wang

Source Links

Description:
Apache Fory can already generate high-performance Java and Python model code from IDL, but end-to-end Java/Python gRPC integration is not available as a unified workflow.

This project will implement Java and Python gRPC integration in the Fory compiler by generating language-specific service and transport artifacts.
Java output artifacts: *Service.java and *Grpc.java.
Python output artifacts: *_service.py and *_grpc.py.

The implementation must use Fory serialization only, without protobuf runtime payload types. It must follow compiler conventions and keep runtime overhead low.

Expected outcomes:
1. Generate Java and Python gRPC service and binding code from service definitions.
2. Support unary and streaming RPC APIs based on Fory service IR.
3. Generate Fory-based request and response marshalling for both languages.
4. Implement zero-copy decode paths for inbound payloads in both Java and Python, with a safe fallback path when zero-copy cannot be applied.
5. Add golden code generation tests for output file names and key method signatures in both Java and Python generators.
6. Provide runnable Java and Python gRPC examples using generated stubs and Fory codec.
7. Update compiler documentation for Java and Python gRPC code generation usage and constraints.

Required cross-language gRPC tests between Java and Python services:
1. Add integration tests for Java server with Python client.
2. Add integration tests for Python server with Java client.
3. Cover request and response round-trip correctness using Fory-serialized payloads.
4. Include unary RPC coverage as required. Include streaming coverage when corresponding generated streaming APIs are in scope.
5. Validate compatibility for normal cases and key error paths, including decode errors and type mismatch.
6. Add coverage for zero-copy decode paths and fallback behavior in both Java and Python integrations.

CI end-to-end test requirements:
1. Add Java and Python gRPC end-to-end interoperability tests into CI.
2. CI must execute both directions: Java server to Python client, and Python server to Java client.
3. CI must fail on serialization compatibility regressions.
4. CI should run deterministic test cases with stable assertions for payload correctness and error handling behavior.

Skills:
Java, Python, gRPC Java, grpcio, compiler and code generation, serialization internals, testing, performance optimization.

Difficulty:
Medium to Hard.

Project size:
Preferred 350 hours.

Potential mentors:
Chaokun Yang, Weipeng Wang.

Source links:

• https://github.com/apache/fory/issues/

• 3370
• https://

• fory.apache.

• org/

• docs/

• next/

• compiler/

• compiler_guide
• https://

• github.com/apache

• /

• fory/

• tree/

• main/compiler

• https://github.com/apache/fory/tree/main/compiler/fory_compiler
• https://github.com/apache/fory/tree

• /main/compiler/fory_compiler/tests
• https://github.com/apache/fory/tree/main/

• swift
• https://fory.apache.org/docs/

• guide/

• rust/
• https://

• github.

• com/

• grpc/grpc-swift

Description:
Apache Fory can generate high-performance C++ and Rust model code from IDL, but it does not yet provide end-to-end gRPC service binding generation for both languages as one aligned workflow.

This project will add C++ and Rust gRPC code generation in the Fory compiler using Fory serialization instead of protobuf runtime payload types.

C++ generated outputs:

• service.h for service API abstractions.
• service.grpc.h for gRPC declarations.
• service.grpc.cc for gRPC implementations.

Rust generated outputs:

• service.rs for service API traits/modules.
• service_grpc.rs for tonic server/client transport bindings.

The implementation should follow Fory compiler conventions and prioritize performance-first, low-overhead runtime behavior.

Expected outcomes:
1. Parse service IR and generate C++ and Rust gRPC outputs from service definitions.
2. Support unary and streaming RPC method generation in both language targets.
3. Generate clear separation between language-level API abstractions and transport bindings.
4. Generate C++ abstract service interfaces and client stubs compatible with gRPC C++.
5. Generate Rust tonic-compatible async server and client wrappers.
6. Implement Fory-based request and response serialization hooks for both C++ and Rust generated bindings.
7. Implement zero-copy deserialization buffer support for inbound gRPC payloads in both languages, with safe fallback when zero-copy cannot be applied.
8. Add golden code generation tests for generated file names and key method signatures in both targets.
9. Add runtime tests for codec round-trip behavior, error handling, and fallback behavior.
10. Add interoperability tests for C++ and Rust generated services, including C++ server with Rust client and Rust server with C++ client.
11. Provide runnable C++ and Rust server/client examples using generated bindings and Fory codec.
12. Update compiler and language documentation for C++/Rust gRPC code generation usage and constraints.

CI requirements:
1. Add C++ and Rust gRPC code generation tests to CI.
2. Add C++ and Rust runtime tests for generated codec and service bindings to CI.
3. CI must fail on generated API signature regressions and serialization compatibility regressions.

Skills:
C++ 17, Rust, gRPC, tonic, compiler and code generation, serialization internals, async Rust, testing, performance optimization.

Difficulty:
Medium to Hard.

Project size:
Preferred 350 hours.

Potential mentors:
Chaokun Yang, Weipeng Wang.

Source links:
https://github.com/apache/fory/issues/3276
https://github.com/apache/fory/issues/3275
https://fory.apache.org/docs/next/compiler/compiler_guide
https://github.com/apache/fory/tree/main/compiler
https://github.com/apache/fory/tree/main/cpp
https://github.com/apache/fory/tree/main/rust
https://fory.apache.org/docs/guide/cpp/
https://fory.apache.org/docs/guide/rust/

Description:
Apache Fory can generate high-performance model code for Go and JavaScript/TypeScript from IDL, but end-to-end gRPC service binding generation across these two ecosystems is not yet complete as a unified workflow.
This project will add Go and JavaScript/TypeScript gRPC code generation to the Fory compiler using Fory serialization instead of protobuf runtime payload types.
The implementation should follow Fory compiler conventions, remain dependency-light in runtime layers, and prioritize low-overhead, performance-first behavior.

Potential Outcomes:

1. Parse service IR and generate Go and JavaScript/TypeScript gRPC outputs for unary and streaming methods.
2. Generate Go outputs `_service.go` and `_grpc.go` with ServiceDesc, server interfaces, and client wrappers compatible with grpc-go.
3. Generate JavaScript/TypeScript service interface and gRPC binding outputs compatible with @grpc/grpc-js and existing JS/TS generator layout conventions.
4. Wire request/response payload handling through generated Fory serializer and deserializer functions in both targets.
5. Implement zero-copy deserialization buffer support for inbound gRPC payloads in both Go and JavaScript runtimes, with safe fallback paths when zero-copy cannot be applied.
6. Coordinate with JS/TS type generation so emitted message, enum, and union types are directly usable by generated gRPC stubs.
7. Add golden codegen tests for generated file names and key signatures for both language targets.
8. Add end-to-end interoperability tests between generated Go and JavaScript services, including Go server with JS client and JS server with Go client.
9. Add CI coverage for codegen tests, runtime codec tests, and Go<->JavaScript gRPC interoperability tests.
10. Provide runnable Go and JavaScript/TypeScript server-client examples using generated bindings and Fory codec.
11. Update compiler documentation for Go and JavaScript/TypeScript gRPC code generation usage and constraints.

Skills:
Go, JavaScript/TypeScript, Node.js, gRPC (grpc-go and @grpc/grpc-js), compiler/code generation, serialization internals, testing, performance optimization.

Difficulty:
Medium to Hard
 
Project size:
350 hours

Potential mentors:
Chaokun Yang, Weipeng Wang

Source links:

1. https://github.com/apache/fory/issues/3274
2. https://github.com/apache/fory/issues/3278
3. https://github.com/apache/fory/issues/3280
4. https://fory.apache.org/docs/next/compiler/compiler_guide
5. https://github.com/apache/fory/tree/main/compiler
6. https://github.com/apache/fory/tree/main/go
7. https://github.com/apache/fory/tree/main/javascript
8. https://fory.apache.org/docs/guide/go/

Description:
Fory Java currently does not provide production-ready Android support. Several Java runtime assumptions do not hold consistently on Android, and some existing runtime mechanisms are not suitable for mobile constraints.
 
Known limitations in current Java path:
1. Android reflection is very slow.
2. JDK `Unsafe` APIs are unavailable or inconsistent across Android versions.
3. JDK `MethodHandle` APIs are unavailable for many Android versions.
4. Bytecode generated by Janino cannot run on Android.
5. Generating source/bytecode on mobile devices is slow and resource-intensive.
 
This project will deliver production-ready Android support for Fory Java serialization while preserving high performance and compatibility with existing Java behavior.
 
Expected outcomes:
1. Keep reflection usage on Android only in very rare code paths.
2. Add Android-specific `Buffer` and utility implementations guarded by a static final `IS_ANDROID` constant, and route Android code paths early.
3. Avoid `MethodHandle` in Android execution paths.
4. Avoid runtime bytecode generation on Android; update `java/fory-core/src/main/java/org/apache/fory/builder` to generate stable source code compatible across Android/JDK versions.
5. Add an annotation processor that invokes the builder pipeline at build time to generate serializer code.
6. Integrate generated serializers with current type resolver so generated code is used for serialization.
7. Validate no performance regression with `benchmarks/java` comparisons against current Java path.
8. Add CI coverage and comprehensive Android tests for compatibility and correctness.
9. Update Fory Java documentation and add a dedicated Android support guide.
 
Required Android verification and test coverage:
1. Add unit tests for Android-specific utility and buffer code paths.
2. Add serializer selection tests to verify generated serializers are preferred in resolver flow.
3. Add compatibility tests across representative Android API levels.
4. Add tests for fallback paths when generated serializers are unavailable.
5. Add performance benchmark runs and regression checks for representative payloads.
 
CI end-to-end requirements:
1. Add Android CI workflow/jobs for build and test validation.
2. Run Android-targeted tests for key serialization scenarios in CI.
3. Fail CI on compatibility regressions that violate project thresholds.
 
Skills:
Java, Android runtime internals, annotation processing, code generation, serialization internals, benchmarking, testing, CI automation.
 
Difficulty:
Hard.
 
Project size:
Preferred 350 hours.
 
Potential mentors:
Chaokun Yang, Weipeng Wang.
 
Related links:
https://github.com/apache/fory/issues/3405
https://github.com/apache/fory/issues/1101
https://github.com/apache/fory/issues/2435
https://github.com/apache/fory/tree/main/java
https://fory.apache.org/docs/guide/java/
https://fory.apache.org/docs/compiler/
 

Apache HugeGraph is a fast-speed and highly-scalable graph database/computing/AI ecosystem. Billions of vertices and edges can be easily stored into and queried from HugeGraph due to its excellent OLTP ability. ​​

Description

Currently, the HugeGraph core query engine is built on Java 11 + TinkerPop 3.5.x + Groovy 3. While this stack provides fundamental graph query capabilities, it lags behind in security, performance optimization, and support for modern features. Specifically, the built-in Groovy engine relies on complex, high-maintenance black/whitelist mechanisms for script security, which poses potential bypass risks.

The goal of this task is to comprehensively upgrade HugeGraph's underlying dependencies to Java 17 + TinkerPop 3.7/3.8 + Groovy 4. This is not just a version iteration, but a modern architectural transformation:

1. Groovy 4 & TinkerPop 3.7/3.8: Introduce improved syntax features and security designs. We aim to refactor HugeGraphSecurity using native, efficient sandboxing mechanisms to replace the legacy blacklist logic.
2. Java 17/21 Support: Adapt to the new JDK to fully leverage features like ZGC/Shenandoah GC, Records, and Virtual Threads, significantly improving throughput and reducing long-tail latency in large-scale graph queries.

Applicants are expected to handle the full lifecycle, from dependency upgrades and code refactoring to unit test fixes and final performance benchmarking.

Recommended Skills

1. Java Core: Proficiency in Java development with a solid understanding of Java 17+ new features.
2. HugeGraph Architecture: Basic understanding of HugeGraph's storage structure (KV Store), Schema design, and specifically the Gremlin query execution flow.
3. Graph Computing & Compilers: Familiarity with the TinkerPop Gremlin framework architecture; knowledge of AST (Abstract Syntax Tree) parsing or Functional Programming (FP) mindset is a plus.
4. AI Coding: Proficiency in using AI Coding tools (e.g., Codex, Claude Code, Copilot) to assist in code refactoring, test case optimization, and source code interpretation is highly preferred.
5. Security Awareness: Awareness of code security, understanding of how to prevent Script Injection, and experience designing secure sandbox environments.

💡 Important Notes for Applicants

1. Authenticity Matters: While we encourage the use of AI for coding efficiency, please strictly control and reasonably limit the use of LLMs when writing your project proposal/emails. We value genuine communication and mutual respect.
2. Proactive Engagement: We highly recommend participating in community Mini Tasks early. Demonstrating your hands-on ability within the community will significantly increase your chances of selection and help build trust with mentors.

Task List

• Dependency Analysis & Upgrade:
  • Analyze Breaking Changes from TinkerPop 3.5 to 3.7/3.8.
  • Complete core dependency version upgrades and API adaptations following mentor confirmation.

• Java 17 Environment Adaptation:
  • Resolve compile-time and runtime compatibility issues (e.g., reflection restrictions, module access) to ensure the Server module runs correctly on Java 17 (Java 21 is even better).
  • Update Docker configurations to migrate the default runtime to Java 17 (while exploring backward compatibility with Java 11).

• PD & Store Module Upgrade (New):
  • Extend the upgrade scope to the PD (Placement Driver) and Store modules after completing the core Server upgrade.
  • Ensure these modules are adapted to Java 17 to unify the runtime environment across the HugeGraph ecosystem.

• Security Module Refactoring:
  • Refactor the HugeGraphSecurity component based on Groovy 4 features.
  • Design a lightweight, secure script execution strategy and remove the performance-heavy legacy blacklist logic.

• Testing & Fixes:
  • Fix Unit Test (UT) failures caused by the upgrade.
  • Ensure all core functions (CRUD, complex Gremlin queries) pass verification.

• Performance Benchmarking:
  • Produce a performance comparison report: Java 11 (Old) vs. Java 17 (New) using the Twitter-14B public dataset.
  • Quantify improvements in Latency reduction and Throughput increases.

References

• New Contributor Guide: HugeGraph Contribution Guide (Issue #2212) - Environment setup & basics.

• Upgrade Docs: TinkerPop Upgrade Documentation

• Reference Implementation: JanusGraph Upgrade PR (For reference only)

• Gremlin Learning: Practical Gremlin Guide

• Project Wiki: HugeGraph Deepwiki

Project Size

• Difficulty: Medium (Similar references available)

• Estimated Time: ~250 Hours (~15 Weeks)

Mentors

• Yan Zhang: vaughn@apache.org (Apache HugeGraph PMC)

• Imba Jin: jin@apache.org (Apache HugeGraph PMC)

Description

Apache Fory does not yet generate Dart gRPC service bindings.

This project will add Dart gRPC code generation to the Fory compiler. For each service definition, the compiler should generate Dart service interfaces and gRPC transport bindings that follow the existing Dart generator layout and use a Fory codec instead of protobuf runtime payload types.

The implementation must keep the Fory runtime free of gRPC dependencies. Any required gRPC glue should be emitted as generated helper code. Runtime behavior should remain low-overhead and allocation-conscious.

Potential Outcomes

• Generate Dart service interface and gRPC binding outputs from service definitions, aligned with current Dart generator conventions.
• Generate Dart gRPC server and client stubs for unary and streaming RPCs using Dart gRPC APIs.
• Wire request/response handling through generated Fory serializer and deserializer functions.
• Implement zero-copy deserialization buffer support for inbound gRPC payloads, with a safe fallback path when zero-copy cannot be applied.
• Coordinate with Dart type generation so emitted message, enum, and union types are directly usable by generated gRPC stubs.
• Add golden codegen tests for generated file names and key signatures.
• Provide a runnable Dart server/client example using generated bindings and the Fory codec.
• Update compiler documentation for Dart gRPC code generation usage and constraints.

Skills：Dart, gRPC (`grpc`), compiler/code generation, serialization internals, async programming, testing, performance optimization.

Difficulty： Medium
Project size：175 hours
Potential mentors：Chaokun Yang, Weipeng Wang
Source links：