As part of the ongoing transition to the module system, CORBA and other Java EE modules won't be included in the default classpath from Java 9 onwards. These modules will still be included in the default distributions, but developers will have to include specific command line flags to be able to use them. The change will only affect non-modular applications targeting Java 9, as modular ones already need to explicitly indicate all the modules they depend on.

As explained in the The State of the Module System, the addition of modular capabilities to Java 9 won't force developers to use them straightaway, instead, a number of backwards-compatible options are being provided. One of these will allow the compilation of traditional, non-modular code in Java 9. For this to work, non-modular code will be added by the compiler to a special module called the "unnamed module", which by default exposes all the packages there contained and has no explicit dependencies.

Unfortunately, the fact that the unnamed module doesn't have any explicit dependencies imposes challenges to module resolution. In a modular Java application, the module being compiled will have an explicit list of needed dependencies. The compiler can use this information, together with the dependencies of the dependencies, to compute a graph that includes the transitive-closure of all modules needed directly or indirectly by the compiled module. Since the unnamed module doesn't indicate any dependencies, it cannot be used as a root to compute the module graph.

In order to fix this, Java 9 will have to use some default value as the root module when compiling code into the unnamed module. With the latest change, this default root module has been changed from java.se.ee to java.se, which means all the Java EE extensions are now unavailable by default. This change will help prevent clashes with application servers that include their own implementations of Java EE packages.