So my understanding of this task is that ideally Jandex could replace reflection metadata provider

Right, it would be an alternative to / replacement for the current AnnotationMetadataProvider.

This new provider can be extended from MetaDataProviderKeyedByClassName, right ?

Yes, that'd make sense. The current annotation based provider does its work lazily, this would have to change for the Jandex-based variant, as we should release the index quickly. E.g. in WildFly it probably is going to be closed (releasing its resources) after the deployment of the application has finished.

Will this provide any benefit in the end ?

It's not a problem per se to have references to let's say Member from within a constraint location. I.e. the target is not to get rid of any reference to the Java reflection API. Instead the idea is to accelerate the retrieval of annotation information (which Jandex is supposedly speeding up a fair bit) by avoiding the calls to getAnnotation().

Eventually we'll have to make some measurements with JMH how it changes things. When the index is passed in to us from WildFly, it should definitely be an improvement. But we also have the case where HV is used stand-alone, in which case we may have to create the index ourselves which of course also takes some time. There are these cases:

• WildFly passes in the IndexView to us
• A JAR provided by the user already contains an index (supposedly there are tools to create an index at build time and add it to a JAR)
• No index is passed in and none has been created at build time, in which case we'd have to build it ourselves

I hope that helps a bit?