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.