What is the significance of java.se module in Java 9?

Question

Why does java 9 module system has java.se module which has transitive dependencies on other modules. Isn't it same as depending upon entire rt.jar in pre Java 9 world.

module java.se {
    requires transitive java.desktop;
    requires transitive java.security.jgss;
    requires transitive java.security.sasl;
    requires transitive java.management;
    requires transitive java.logging;
    requires transitive java.datatransfer;
    requires transitive java.sql.rowset;
    requires transitive java.compiler;
    requires transitive java.sql;
    requires transitive java.naming;
    requires transitive java.prefs;
    requires transitive java.rmi;
    requires transitive java.xml.crypto;
    requires transitive java.management.rmi;
    requires transitive java.xml;
    requires transitive java.scripting;
    requires transitive java.instrument;
}

Abeyance

Why is that surprising? It seems convenient, otherwise you'd have to include every dependency manually. – Tigre

java.se includes only a limited set of modules. The full set of modules is much bigger: JavaFX, XML, Corba etc. – Roslyn

@JornVernee- I think we will have to include most module dependencies manually. Those transitive will be resolved automatically – Abeyance

Answer 1

As far as I can tell the main reason is compatibility with non-modular Java EE code. When code that has no module declaration or descriptor (which defines its dependencies) is compiled or launched, the question arises which modules from the JDK it is allowed to "see".

If those were all modules in the JDK, then the Java EE ones would "overshadow" any Java EE implementations that are put onto the class path. This is a peculiarity of the interaction between modules and the class path (which ends up in the unnamed module): if a package is present in both a regular module and the unnamed one, the latter will be effectively invisible.

To remedy that fact not all modules will be visible for code on the class path. Instead, module resolution (which resolves an application's dependencies) will begin in the root module java.se, thus ignoring Java EE modules.

For a more detailed explanation, have a look at this mail from Alan Bateman, in which he explains the change of the corresponding JEP 261.

Cartesian

Thanks! I thought for backward compatibility jars would still be there in jdk-9. – Abeyance

They totally are! JARs are still the primary container to ship classes around. The only change is that they might contain a module descriptor (module-info.class), in which case they are a modular JAR. – Cartesian

Answer 2

The java.se module is the default set of modules (aka "root modules") available to applications in Java 9. You are right that the java.se module is about 80% of what was in the rt.jar of older JDKs (if you want to full rt.jar take a look at the java.se.ee module).

One key advantage of Java 9 modularity is the new jlink utility, which will "minify" your JDK to only the modules that are needed. For example, suppose you write a very simple Java app that only depends on the java.base module and you want to distribute in the smallest possible form. You can run the jlink utility to create a JDK image that would contain only contain the java.base module, because that's all your application requires in order to run.

Getting back to the java.se module, it would probably be foolish to write a module that requires java.se because this would ruin the possibility of jlink ever creating a nice small JDK image for that module or any other modules that depended on it. In an ideal world, all modules declare the precise modules that they require.

Spasm

The compact aggregator modules were removed some time ago. – Cartesian

Thanks for pointing that out, I've updated my answer. Sadly the JEP 261 page still mentions them so I assumed they still existed... – Spasm