Creating this issue as we spoke about the possibility to use Jandex a few times, so we have a one place for discussions.
Fast meta-data retrieval when using pre-existing index
Not so good documented
Implementation-wise it would make sense to implement this in form of another MetaDataProvider.
We could also make meta data providers more pluggable, so we don't have a strict dependeny to this. The Jandex provider would then be plugged in under AS while in other scenarios the normal annotation-based provider would be used.
pointed out that it may be that in WildFly the Jandex index isn't available after boot/deployment. Probably need some discussion on wildfly-dev.
Hi , so indeed the Jandex index will not be available after bootstrap. This means we need to eagerly build up the meta-data for all types present in the index. Types present in the annotation index which are unconstrained would be represented by UnconstrainedEntityMetaDataSingleton. The XML-based meta-data provider can be taken as an example for an eager meta-data provider. For experimenting, we could build the index ourselves (should be described in the Jandex docs) and pass it into HV via a new property or method on HibernateValidatorConfiguration.
Would you be interested in hacking on this?
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
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?
yes, thanks !