[FEATURE] Unified flagd-evaluator PoC (Java/Python/...) – reduced maintenance, PoC, and reference

Requirements

This issue summarizes the initial efforts around the new Rust-based "flagd-evaluator" PoC and the integration of this unified implementation with Java and Python SDKs.

References:

• flagd-evaluator repository: https://github.com/open-feature-forking/flagd-evaluator
• flagd-evaluator latest release (v0.1.1): https://github.com/open-feature-forking/flagd-evaluator/releases/tag/v0.1.1
• Python SDK PoC: https://github.com/open-feature/python-sdk-contrib/pull/328
• Java SDK PoC: https://github.com/open-feature/java-sdk-contrib/pull/1672
• Rust SDK PoC: https://github.com/open-feature/rust-sdk-contrib/pull/94

Highlights:

• The flagd-evaluator is now a WASM-compiled Rust implementation, designed for reuse across SDKs and languages via WASM adapters.
• Recognized reduction in maintenance burden by having a single unified logic core, replacing divergent and duplicated implementations in each language SDK.
• The logic for the evaluator was mainly copied and adapted from the existing Rust flagd provider, acknowledging original authorship and design origins.

Disclaimer:
These efforts are strictly a Proof of Concept (PoC) and side project explorations, intended to validate the unified evaluator approach.
All implementations referenced are experimental, incomplete, and require further evaluation, polish, and design discussion.
Please do not consider any of the PoC integrations production-ready! These are provided to open up community feedback and provoke discussion on future direction.
More rigorous review and additional time should be invested into making these approaches robust.

Next Steps / Callouts:

• Seeking feedback from maintainers and users on this approach.
• Questions around performance, API flexibility, and safety/validation still need thorough investigation.
• Not intended for production without further maturation.

Summary: This unified approach should lead to easier updates, reduced maintenance, and more consistent behavior across SDKs. Community input is welcome at this early stage.

Performance

Benchmark Comparison: WASM vs Native JsonLogic in Java

Comprehensive JMH benchmarks comparing the new WASM evaluator against the existing native Java JsonLogic resolver:

Key Findings:

• WASM has ~3-4µs baseline overhead per call (unavoidable)
• For complex targeting with large contexts, context serialization dominates
• Short-circuit optimization helps significantly for flags without targeting
• Pre-allocated buffers eliminate per-evaluation allocation overhead

Start by reviewing the flagd-evaluator v0.1.1 release and the referenced Python, Java, and Rust SDK PoCs, then compare the JMH benchmark table with the existing Java resolver. Done is not defined here: maintainers still need to decide whether the experimental WASM approach meets performance, API flexibility, and safety requirements.