Spring's need for optional dependencies

[Juergen Hoeller]

Hi everybody,

Juergen from the Spring team here. Quick intro: Spring Framework project
lead since 2003, currently focusing on the Spring Framework 4.3 / 5.0
strategy for 2016-2017.

After extensive conversations with Mark and Alan at Devoxx Belgium in
November, I'd like to summarize our need for optional dependencies from
Spring's perspective:

Our module arrangement in the Spring Framework project has been pretty
stable for about 10 years, splitting the core framework into ~20 modules
with a maximum size of ~1 MB each (some are much smaller). The module split
is largely based on domain (e.g. aop, beans, jdbc, messaging, orm, web,
webmvc, websocket), with each of those modules bringing in a few required
dependencies but in particular also optional dependencies which only apply
when certain third-party frameworks are used in combination with Spring.
Such external frameworks are up for the user to choose; Spring just reacts
to their presence and auto-configures itself for integration with those
frameworks. For example, when Jackson is present, we automatically register
message converters for it; when Joda-Time is present, we automatically
register type converters for its value types. This auto-configuration
experience is long-established in the Spring world, not only for
third-party libraries but also for the JDK: currently between 6, 7 and 8,
for example registering java.time converters automatically when JDK 8 is
present (along the lines of our Joda-Time support).

We have had tight OSGi alignment a few years back, with the framework
modules shipping bundle manifests out of the box. We backed out of this
again since it turned out to be a pain to maintain on our side, in
particular due to the inclusion of version ranges but also due to the
extensive length of the resulting manifests in our jar files. There are
still variants of the Spring modules which include OSGi metadata but they
are maintained by the Virgo project at Eclipse. The canonical Spring
Framework jars from Maven Central come without any such metadata at present.

Now, as of Spring Framework 5, we aim for being the best possible citizens
in a Jigsaw world (while retaining compatibility with JDK 8 at the same
time). Our roadmap is closely aligned with JDK 9 there, and we've got a
first milestone scheduled for June 2016 now. However, there is a
showstopper with Jigsaw: We cannot express the above-mentioned optional
dependencies at this point. Note that Spring's auto-configuration
experience just implies optionality at runtime; those dependencies are in
fact required at compile-time. We'd just like to let our framework modules
bootstrap even when none of those optional dependencies are present,
dealing with the resulting ClassNotFoundExceptions ourselves (we're simply
checking for the presence of certain classes and derive auto-configuration
decisions on that basis). This has been working pretty well for us for 10+
years, and we really need this to keep working when declaring our framework
modules with Jigsaw-compliant module-info files. After all, we'd love to
ship explicit metadata, not keep relying on classpath-like deployment where
such implicit access to other modules remains available.

The alternative would be decomposing the framework into finer-grained
modules which isolate each such dependency into its own module. Aside from
bumping up the number of core framework modules from ~20 to >50 that way,
we'd also lose most of our auto-configuration experience. Making the user
declare such integration modules explicitly is exactly what we're trying to
avoid: Instead, declaring a specific Spring module and a specific
third-party module should be all that it takes, e.g. spring-webmvc and
jackson-databind but no extra spring-webmvc-jackson.

So in summary, we have a strong need for some kind of optional marker in
Jigsaw dependency declarations, similar to optional resolution in OSGi.
Runtime optionality is all that it takes for our purposes: no different
treatment at compile time needed, just lenient bootstrapping which lets us
run into ClassNotFoundExceptions and deal with those. I imagine other
frameworks will be in a similar situation.

It'd be my pleasure to discuss our requirements in more detail if needed...

Juergen