Stable module names for Spring Framework jars on JDK 9 module path [SPR-13716]

[spring-projects-issues]

Juergen Hoeller opened SPR-13716 and commented

As of Spring Framework 5.0, we intend to allow Spring Framework jars themselves to live on the JDK 9 module path. Since other libraries such as Commons Lang and JUnit 5 start declaring the Automatic-Module-Name manifest header explicitly (instead of relying on a filename-derived module name), let's consider doing the same for 5.0 GA already.

Even if our preference is towards spring.context style naming which would actually be the same as the outcome of JDK 9's filename-based algorithm, it's a feature in its own right to provide stable names which are independently from actual jar file names (potentially renamed for a custom build arrangement) in any given setup.

---

Issue Links:

• Compatibility with merged JDK 9 mainline [SPR-13344] #17928 Compatibility with merged JDK 9 mainline ("depends on")
• Declare Spring modules with JDK 9 module metadata [SPR-13501] #18079 Declare Spring modules with JDK 9 module metadata ("is depended on by")
• AMQP-769 Stable module names for Spring AMQP jars on JDK 9 module path
• INT-4346 Stable module names for Spring Integration jars on JDK 9 module path
• Document Spring recommendations/restrictions for Java 9 module setups [SPR-14579] #19148 Document Spring recommendations/restrictions for Java 9 module setups
• Upgrade to Gradle 4.1 for clean JDK 9 build compatibility [SPR-15667] #20226 Upgrade to Gradle 4.1 for clean JDK 9 build compatibility
• Compatibility with JDK 9 GA [SPR-15992] #18941 Compatibility with JDK 9 GA

0 votes, 13 watchers

[spring-projects-issues]

Philippe Marschall commented

Is that realistic sine:

• Jigsaw won't include optional dependencies (that's at least the last word I heard)
• the module names of a lot of third party modules are unclear, especially all Java EE dependencies

[spring-projects-issues]

Juergen Hoeller commented

Well, point taken, and there are indeed no guarantees. I've talked to Mark Reinhold and Alan Bateman about it at quite some length last November, so they are well aware that no optional dependencies in Jigsaw means no shipping of Spring Framework or Spring Boot jars as proper Jigsaw modules. If that is the outcome, we'd have to keep recommending classpath usage or possibly some of JDK 9's automatic jar-to-module support, but we definitely won't ship explicit module declarations then. We'd "just" aim for compatibility with JDK 9 in general, pick up java.util.concurrent.Flow when declared in reactive endpoint signatures, that sort of stuff.

At least our requirement is formally stated as "Compile-Time Dependencies" at http://openjdk.java.net/projects/jigsaw/spec/issues/ in the meantime; let's see where it goes from here. Frankly, if they don't pick this up for JDK 9 GA still, I'd be seriously disappointed, and certainly not just me. We'd end up with another rather non-practical module system then, destined to never make it into the enterprise mainstream... despite having occupied key resources in the JDK team for several years. And there's nothing we can do about it from our side: Spring Boot's configuration experience can only be delivered in a sane fashion with an optional dependency arrangement.

So since you're also a stakeholder there: Your hopes aren't particularly high? Where have you heard about it lately?

[spring-projects-issues]

Philippe Marschall commented

Experience with OSGi has thought us about the challenges of running existing software in a modular environment. OSGi has a lot of work arounds (buddy classloding, dynamic imports, fragments, …) to make various code work. These are currently all missing from Jigsaw. The only special exception seems to have been made for ServiceLoader. To give you an example I don't see how the current code base of either slf4j or commons-logging would work in Jigsaw (without JVM flags). They would all have to be moved to ServiceLoader. Even then things like icl-over-slf4j would likely break. These are simple scenarios not complicated ones like getting Java EE to work in Jigsaw.

Running Spring Boot in a stripped down, optimized JRE certainly seems compelling. But looking at the module graph of Jigsaw makes me wonder if anything besides CORBA can realistically be left out. To give you an example Java Beans are located in the "java.desktop" module together with AWT, Swing, probably Sound and who knows what else. Java Beans support in Spring would have to be made optional if you want to deploy on a JRE without AWT and Swing.

Running Spring using JDK 9's automatic jar-to-module support doesn't seem realistic to me. It is my understanding that one would have to use JVM flags to set the dependencies for Spring (commons-logging, aopalliance and whatever optional dependencies of Spring one wants to use) and all of these dependencies would have to be modules again, either "native" Java 9 modules or using JDK 9's automatic jar-to-module support and JVM flags for their dependencies.

Given the magnitude of the challenges even the revised schedule (feature complete by 2016-05-26, before Spring 4.3 GA) seems ambitious.

[spring-projects-issues]

Juergen Hoeller commented

Absolutely, the JDK 9 feature freeze in late May is a tough one from where we are now. My expectation is that they'll postpone it once again, along with the JDK 9 GA date...

In any case, from Spring's perspective, we are going to keep recommending classpath usage if we cannot achieve our configuration experience using Jigsaw. And as you point out, many EE environments suffer from the same issues, in particular many of the libraries (Hibernate? JPA in general? etc). Mark and Alan are aware of this; if they decide to nevertheless limit Jigsaw to what it is today, its appeal will be limited from the start... and it might never properly make into enterprise environments.

For our planning purposes, we assume that JDK 8 is going to be the baseline for a long time to come. The rather eager upgrading to JDK 8 across the industry last year is probably a one-time effect only, with very little chance of that getting repeated for JDK 9. Or more specifically, the rather eager embracing of JDK 8 overall - with its actual language and library features - was a unique effect: If people upgrade to JDK 9, it might just be for maintenance policy reasons, with the applications still developed at JDK 8 level.

So in terms of our concrete plans: For Spring Framework 4.3 GA, we aim for runtime compatibility with the late-May state of JDK 9, and will be tracking it for the 4.3.x line until JDK 9 GA, effectively supporting four generations of the JDK in a single, long-lived framework generation. Next year, Spring Framework 5.0 will be primarily driven by the JDK 8+ codebase upgrade and our reactive efforts, with our own GA target in March 2017. Dedicated JDK 9 support is a bonus, just like Servlet 4.0; if delayed, we'll pick it up in 5.1 later on.

[spring-projects-issues]

Philippe Marschall commented

We are still eagerly awaiting JDK9 and will be trying to switch ASAP independently of Jigsaw. If compact strings delivers what it promises it's going to be a huge performance improvement to our applications without a single code change. Besides this there are so may other improvements that will make the switch worth it for us even without a single code change.

So for us the most important thing is that Spring runs in classpath mode on JDK 9. I don't see us using Jigsaw modules in the foreseeable future independent of what the final verdict on optional dependencies will be.

[spring-projects-issues]

Juergen Hoeller commented

Good point, the runtime improvements alone will be worth it. This - and Oracle's maintenance policy - will be reason enough that existing Spring 4.x based applications will be deployed it without any actual JDK 9 language or API usage... and of course in classpath mode. And granted, this is exactly what we're aiming for in Spring Framework 4.3.x already.

For Spring Framework 5.0, beyond Jigsaw, the new JDK 9 HTTP client (if it eventually materializes) and java.util.concurrent.Flow are certainly worth picking up. So even without actual Jigsaw support, we'll build the 5.x framework against JDK 9 (with -target 1.8 of course) as soon as possible in order to call those APIs without reflection.

[spring-projects-issues]

Juergen Hoeller commented

This issue has been narrowed to more modest purposes, focusing on any use of Spring Frameworks jars on the JDK 9 module path, in particular also as "automatic modules", i.e. putting our regular jars onto the module path and letting them participate in a module-based arrangement that way (with implicit access to all other modules).

The original #18079 tracks actual module-info.java declarations in our own jars (which seems rather unlikely at this point).

[spring-projects-issues]

Juergen Hoeller commented

The Jigsaw page has just been updated with a proposal towards optional dependencies:
http://openjdk.java.net/projects/jigsaw/spec/issues/#CompileTimeDependences

However, since that effort certainly won't deliver in time for our 5.0 M1, I'll leave our ticket here as declared above, experimenting with general use of our jars on the module path. #18079 will then aim for explicit module declarations later on, possibly in 5.1, provided that a capable optional dependency model actually makes it into JDK 9 proper.

[spring-projects-issues]

Juergen Hoeller commented

As per Paul's comment and the referenced Devoxx video in #19148, all we need to do here for the time being is to document the use of our framework jars on the module path, since even 4.3.x works fine for those purposes already.

#19148 itself tracks our support for classpath scanning in an exploded module layout, i.e. in a directory instead of a jar (the only remaining gap at this point).

[spring-projects-issues]

Juergen Hoeller commented

The main disadvantage of putting the framework jars onto the module path as "automatic jars", i.e. without explicit module-info descriptors, is that we can't transitively expose required dependencies. For example, if an application module declares requires spring.context, this doesn't imply spring-beans, spring-core etc in such a scenario; we can only get such transitive exposure with explicit module metadata (#18079).

For the time being, the best an application module can do is to declare the entire closure of framework modules in the application's module-info, that is, a list of requires spring.x clauses instead of just a single entry point.

[spring-projects-issues]

Juergen Hoeller commented

The limitation that I referred to above seems to be gone: Testing against JDK 9 build 167, transitive resolution of automatic module dependencies works seamlessly now. For Spring applications, the experience is quite alright that way: e.g. requires spring.context is all it takes, with spring.core coming in transparently then, and our framework modules automatically seeing their optional dependencies when present.

[spring-projects-issues]

Juergen Hoeller commented

Please note that this ticket has been slightly repurposed towards providing stable module names through Automatic-Module-Name manifest entries, as per the recently revised issue description.