Deprecate spring-context-indexer

[snicoll]

The Spring Context indexer was introduced as a way to process component scanning of very large applications at build-time. It comes with several limitations, the biggest one being an on/off switch (i.e. as soon as one metadata file is present, all jar files must have been processed with the tool or matching beans won't be found).

In the meantime, our AOT efforts in Spring Framework 6 covers those performance and build-time optimization aspects in a much broader fashion. As we don't intend to further explore the route of the indexer, we're going to deprecate it in favor of AOT.

[mitasov-ra]

Does Spring AOT imply GraalVM usage?

[snicoll]

No.

[vpavic]

It's a shame to see the indexer deprecated (and eventually removed) since it was quite useful in some situations and provided measurable gains during startup.

For older (and larger) applications I don't know how feasible will it be to move to AOT - I would even say that the type of applications that benefited the most from the indexer are the ones least likely to adopt AOT. But also with the new applications I personally don't like being forced to adopt AOT to have optimization of this kind at disposal.

Did indexer incur so much maintenance cost?

[snicoll]

It's not so much the maintenance cost, but rather the fact that the indexer has serious limitations and we know we won't be resolving them. I can see how that can be annoying if it is working fine for you as it is, but, as maintainers, we have to strike a balance between "competing" options, the message it sends and the confusion it could bring.

AOT is not set in stone, far from it. It would be interesting to see how it could be used to handle what the indexer used to do, with less optimizations and therefore more flexibility at runtime.

That being said, we can't remove the indexer before 7.0 at the earliest. We're monitoring this issue and we'll review our position before M1 if necessary.

[vpavic]

FWIW, it seems to me that support for JVM Checkpoint Restore (using CRaC) is perhaps better suited to be considered as the feature that context indexer is deprecated in favor of, simply because it allows developers to continue building their applications as they are used to (unlike AOT).

[sdeleuze]

CRaC has great benefits, but I think it introduces more constraints than AOT (some like fixed application context being common), and has a different nature, so I tend to agree with the line of thinking that AOT is conceptually the successor of the context indexer.

[bclozel]

@shodo the sample application is quite complex and there are a lot of moving parts. The problem might be in the build configuration itself. I'm moving this to a new issue #31307 as it's not related to this particular issue.

[ascopes]

@snicoll Unless I misunderstand...

At the moment, AOT is focused on allowing Spring applications to be deployed as native images using GraalVM. We intend to support more JVM-based use cases in future generations.

Doesn't this imply you do need GraalVM currently?

[sbrannen]

Doesn't this imply you do need GraalVM currently?

No. Previously the "focus" was primarily for use with a GraalVM native image, but it was always possible to use Spring AOT on the JVM, and Spring Framework 6.1 and future generations will provide more first-class support for JVM-based use cases such as CDS (class data sharing), Project Leyden, etc.

Though, you're right: the wording in that note in the reference manual could be improved to make this clearer.

@ascopes, would you like to open an issue to address that topic?

[ascopes]

Thanks for the quick response!

I'll have to see if I have some time at the weekend to throw something together, but happy to take a look!