Redesign Reflection Engine for Jakarta Data Repository

[otaviojava]

Introduce a redesigned engine for handling method introspection and metadata in Jakarta Data repositories to support modern runtime and build-time scenarios better.

The current reflection-based engine processes repository methods at runtime, leading to performance overhead and limited extensibility. As we move toward more sophisticated scenarios—such as supporting functions (Jakarta Data 1.1), Java annotation processors, and integration with Jakarta Persistence—it becomes necessary to rearchitect the engine to be more modular and efficient.

🎯 Goals:

• ✅ Performance: Replace repeated reflection calls with pre-processed metadata, reducing method resolution time by ~10x.
• 🔄 Unification: Support both runtime reflection and build-time annotation processing through a unified metadata model.
• 🔌 Extensibility: Redesign using composition over inheritance to allow future extensions, including use cases in Jakarta Persistence and other specifications.
• 🧩 Interoperability: Lay the foundation for features like query function support, mandatory in SQL but optional in NoSQL, in Jakarta Data 1.1.
• 🔁 Simplification: Centralize customization logic for method parsing, repository interfaces, and parameter handling in one place.

Initially designed for Jakarta Data 1.1, this redesign could also be backported to the 1.1.x line of Eclipse JNoSQL for broader adoption and ecosystem support.

🧪 Performance Expectations:

• Reflection metadata read once at startup vs. repeated reflection calls
• Estimated method call speedup: 10x
• Reduced memory pressure due to caching and metadata reuse

[otaviojava]

@OndroMih FYI.

I saw the extension. Given this scenario, I will work on this to make your life easier on Jakarta Data 1.1.

As soon as I have a proposal, I will let you know.

[otaviojava]

The metamodel is done: https://github.com/eclipse-jnosql/jnosql/pull/658

[otaviojava]

FYI: @OndroMih

This redesign is not only aimed at improving performance, but also at providing a better architectural fit for both SQL and NoSQL implementations. With the new SPI, each repository operation becomes an independent, extensible component, making it straightforward to apply patterns such as extension, decoration, or composition.

Because every operation now has its own well-defined contract, the provider can plug in SQL or NoSQL semantics without bending the model. This gives us a unified execution layer that remains flexible across storage types.

I'll begin implementing the new structure on the JNoSQL side, and once it successfully passes the TCK for Milestone 1, we can move forward with the SQL implementation.

PR for reference: https://github.com/eclipse-jnosql/jnosql/pull/659