Commit dc160f6 contains a first attempt at producing and using the index within the framework code base. Two areas are covered for the moment:
- JPA entities (and friends) detection
- Regular component (typically @Component) detection
The implementation is completely transparent: you use @ComponentScan the regular way and if an index is available it will be used rather than traditional scanning.
Performance wise, it's not super impressive:
- Project with 200 entities, 200 components and 1000 irrelevant classes: 4120ms (scan) vs. 3902ms (index) - 5.3%
- Project with 200 entities, 200 components and 5000 irrelevant classes: 4697ms (scan) vs. 4229ms (index) - 10%
That's the mean of 3 separate executions of a full (Spring Boot) application bootstrap (i.e. including the hibernate bootstrap). The advantage of the index is that the time required to scan candidates is basically constant regardless of the size of the project.
One thing that the implementation doesn't support is the use of custom include filters: the index only knows about a limited set of candidates so as soon as a custom include is set, we have to ressort to classpath scanning. In the app that was tested, several traditional classpath scanning were operated even though the index is available:
- EnableSpringDataWebSupport is looking for SpringDataWebConfigurationMixin
- RepositoryConfigurationDelegate is looking for RepositoryFactorySupport
- RepositoryConfigurationSourceSupport is looking for Repository and RepositoryDefinition
The first two are looking in Spring Data's own package space so it's not that bad since the size of the package is constrained. Still, Spring Data may generate some meta-data file they could lookup rather than scanning the classpath for components.
For the latter, Repository is supported but RepositoryDefinition isn't. This may be a case for moving that annotation processor to Spring Boot where Spring Data is a dependency. That will not let Spring Data use it though. Another option would be to refer to those Data types in Spring Framework (the annotation processor knows about FQN anyway) but it's a bit weird to say the least.