Investigate Jandex

[philwebb]

Jandex is used by WildFly to improve performance when scanning classes. We might be able to write the index during jar creation and pass it to Hibernate or use it ourselves.

[philwebb]

See also SPR-10354 and SPR-11890

[larsgrefer]

You might be interested in what we have done for JoinFaces (JSF inside Spring Boot applications): https://github.com/joinfaces/joinfaces/tree/master/joinfaces-tools

We have a Maven plugin and a Gradle plugin which perform a classpath scan with classgraph at build time in order to improve the application startup time.

Some Background

In order to correctly initialize JSF implementations at runtime, JoinFaces has to call org.apache.myfaces.ee.MyFacesContainerInitializer#onStartup or com.sun.faces.config.FacesInitializer#onStartup supplying a set of classes which match a different criteria. In order to do so, we have to scan the complete classpath.

Performing this scan at runtime added between 2 and 10 seconds to the application startup time. (see #15096) By moving this scan to the build we reduced this part of the startup to 0.2 seconds.

Implementing this as build tool plugin (instead of as annotation processor) has the advantage that we can scan the complete runtime classpath at once.

[OndraZizka]

Any news on this? It's not too complicated to do.

[wilkinsona]

We've done some exploratory work with Jandex and we do not think that it will meet our needs. The information that it indexes is more than we need and, as a result, it's not as memory efficient as we'd like it to be. For example, the indexes that are required for spring-boot-autoconfigure uses approximately 4MB of heap.

[OndraZizka]

@wilkinsona , I am not sure I understand your reason to reject this.

The request for this improvement does not mention memory. It mentions boot duration.

We have relatively small Spring application which takes around 20 seconds to boot, of which a lot is scanning.

That means that each integration test takes way too long to boot.

Could you please reconsider? The change would be just having an additional scanner, which would be backed by the Jandex read.

Yes, it takes a tiny bit of memory, but that one may be dropped after used.

And, it could be optional: If there is a jandex in a jar, then read it in a second; otherwise, scan the classes in 10 seconds.

[OndraZizka]

I found some support for Spring Boot + Jandex, in IBM's WebSphere. So it's already implemented and maybe ready to be officially supported by Spring?

[wilkinsona]

Spring Framework already provides an index for classpath scanning in its spring-context-indexer module. You can learn more about it in Framework's reference documentation.

We don't have any plans to use Jandex at this time as it doesn't meet our needs. Its memory footprint is too large and, in our prototypes, the performance improvements have been negligible. We are, however, exploring several other options for further reducing startup time and memory footprint. A lot of that work is being done in the Spring Native project at the moment. While its primary focus is GraalVM, its ahead-of-time compilation approach also has benefits on the JVM.