Remove dependency on java.desktop and other modules

[brunoborges]

Spring requires the java.desktop module to be present at Java runtimes only so that it can use the classes in the java.beans package.

Would be a good start for modernizing Spring apps on a post Java 9+ era of modules if Spring could at least work on slim Java runtimes produced with jlink.

Other modules to consider adjusting the dependency are java.naming, java.xml, java.sql, jdk.*, java.instrument, java.management,java.rmi, java.scripting.

This is not about making Spring compatible with Java SE modules. This is only to allow developers to have smaller Java runtimes created with jlink.

In an ideal world, a Java runtime, created with the following jlink command should be sufficient to run a Spring Boot Hello World with the Web dependency:

$ jlink \
        --add-modules java.base,java.logging \
        --strip-debug \
        --no-man-pages \
        --no-header-files \
        --compress=2 \
        --output /javaruntime

[dreis2211]

I guess this is more on the Framework side of things at https://github.com/spring-projects/spring-framework. The java.beans package is quite a central piece if you ask me. Boot has a couple of dependencies to java.beans & java.awt as well, but the heavy lifting must be done on the framework side. Let's see what the team has to say on this and if they want to move the ticket there.

Having that said - I'd love to see this in a perfect world, but I doubt it's easy or straightforward, if at all possible.

[jhoeller]

We are aware of our rather wide-spread dependencies across the traditional JDK-scoped libraries. Some of those are entirely optional (e.g. JNDI, JMX, RMI and JSR-223 Scripting are only used on demand and do not have to be present at runtime - at least from the core Spring Framework perspective) but the java.beans package is indeed a hard case. The JDK's own historic misdesign with the unnecessary AWT dependencies in that package caused its inclusion in java.desktop, unfortunately ignoring the common use of the JavaBeans introspector and some of its API types in server-side libraries.

Our only way out is to reimplement the introspection algorithm ourselves and to replace java.beans.PropertyDescriptor and co with corresponding API types of our own, so that's what we're considering for Spring Framework 6.0 (along with the general JDK baseline upgrade and the introduction of module-info definitions across the codebase). This will cause binary compatibility breakage in a few places, but so will the Jakarta EE 9 API migration with its namespace change (also planned for 6.0). So anything we do in that respect, we'll definitely do it for 6.0 (and might then further refine it in 6.x releases).

[brunoborges]

Thanks a lot Juergen for sharing the roadmap for 6.0. This will certainly speed up modernization of Java applications with latest JDK releases, as Spring has become a de facto standard of server side development.

In the meantime, is there official documentation and/or tooling to help developers produce customized jlink runtimes for 5 and older?

Your comment that some modules are optional is key, but I haven't found this in the docs.

[sdeleuze]

That will help on native side as well.

[dsyer]

Here are some more data points. I found that with a vanilla Spring Boot webflux app jdeps will report that it needs

java.base,java.desktop,java.instrument,java.management,java.naming,java.prefs,java.rmi,java.scripting,java.sql,jdk.httpserver,jdk.jfr,jdk.unsupported

(so no XML modules). If you remove the snakeyaml dependency (which needs java.logging) you can run the app with just

java.base,java.desktop,java.naming

You have to add back java.management to get the full logs including JVM uptime and avoid a warning about the PID not being
discovered.

If Spring 6 could shed java.desktop and java.naming that would be cool. The naming dependency comes from CommonAnnotationBeanPostProcessor (there's a reference to a SimpleJndiBeanFactory which is probably never used), so it seems like that could be removed.

I suppose it's an open question for the JDK why jdeps thinks you need all those other modules when actually you don't, at least for the "normal" code paths.

The code I used to test: https://github.com/dsyer/sample-docker-microservice

UPDATE: you can run without java.naming if you use Spring AOT and -DspringAot=true.