Reduce cumulative JAR payload required for DI-only use cases (particularly ANTLR) [SPR-5721]

[spring-projects-issues]

Ben Alex opened SPR-5721 and commented

As discussed over email, there are certain projects that use Spring Framework for dependency injection use cases only (eg the Spring Roo shell). Such projects may have distribution size minimization preferences that are easier to achieve if Spring Framework operated in a base "DI-only" mode with a minimal JAR payload.

The 3.0.0 series of Spring Framework introduced new expression language support, which as of 3.0.0.M3 has a dependency on ANTLR. In 3.0.0.M3 this amounts to 740K of JARs that would ideally be optional for "DI-only" usage. Excluding these JARs in 3.0.0.M3 causes a NoClassDefFoundError (org/antlr/runtime/RecognitionException) due to StandardBeanExpressionResolver.java:57.

It would be desirable if Spring Framework could operate without requiring expression languages JARs. Likewise, any other improvements that could be made to diminish the JAR payload requirements for DI-only use cases would be appreciated.

---

Affects: 3.0 M3

[spring-projects-issues]

Andy Clement commented

Juergen - do you want to soften the dependency or do you really want a new parser? It is rather more complex than the parsers I've written recently, so I'm concerned whether I can get it done in time for RC1

[spring-projects-issues]

Andy Clement commented

Just a note: the Antlr dependency is now gone, and the expression jar is 40k smaller than it was.

[spring-projects-issues]

Juergen Hoeller commented

I consider this done for the moment, since the jar payload is way better than before thanks to Andy's rewriting of the parser.

While we could potentially do further optimizations, even making the org.springframework.expression jar optional, I'm not sure whether that's worth it... since we also want to provide consistent evaluation of expressions and expression-style values, even if expressions are not (deliberately) used in an application. In other words, we also want consistent failure in case of invalid expression values, not suddenly processing them as regular values just because the expression jar isn't present in the classpath.

Juergen

[spring-projects-issues]

Ben Alex commented

Juergen, Andy's work has reduced the payload for EL from ~740Kb to ~140Kb - a saving of ~600Kb. While this is great, I still think it's better if projects not requiring expression capabilities can simply not include the JAR in their classpath.

Concerning the consistent failure issue, would it be possible to detect expression usage and then immediately throw an exception if the JAR is missing? I don't think you need to fallback to standard evaluation: just detect it's missing and abort application context startup. This would represent reasonable behavior in my view and still save ~140Kb. I also know that in time all libraries have a tendency to grow larger, so 140Kb saved today will translate into even larger savings as the years progress. It would also seem useful at this point to decouple EL, underscoring that Spring Framework should be able to operate without the EL JAR available.

This focus on payload size is likely to be renewed when we separate out Spring Shell. At that point we'll have both Spring Roo and Spring Shell seeking minimal footprints.