| I've started some investigation for this task and I thought before I get very deep into it I'll discuss this with you. So my understanding of this task is that ideally Jandex could replace reflection metadata provider (and new provider should be faster, and using nicer API), is this correct ? To do this we'd need a new metadata provider and as you pointed out. This new provider can be extended from MetaDataProviderKeyedByClassName, right ? To do this we'd need to prepare BeanConfigurations.
While going further I hit an "obstacle" - I need to create a ConstraintLocation instance but it is using "reflection" classes. I saw how it is done in XML parser through class loader and so on, but it got me thinking. So in case of XML it seems fine that "reflection" classes are used as XML is a different kind of defining constraints. But in case of Jandex (which as I thought should replace "reflection") we'll be using additional dependency to walk through classes and retrieve metadata and then use "reflection" to build the cached bean definitions.... Will this provide any benefit in the end ? I'm not as familiar with this as you are, so most likely I'm missing something here  |