java.corba and EE modules not resolved by default
Alan.Bateman at oracle.com
Tue May 17 10:46:21 UTC 2016
Just a heads-up that jdk-9+118 includes a refresh of the module system.
There are several changes in this update, the most significant of which
is that the default set of root modules when compiling code in the
unnamed module, or when running code and the main class is loaded from
the class path, is based on the `java.se` module rather than the
`java.se.ee` module. This aligns the implementation with the policy for
root modules that is described in JEP 261 .
So what does gobbledygook mean? It means that if you are compiling or
running code on the class path then types in the following 6 modules
will not be visible by default:
It will "as if" the types in these modules do not exist.
The JEP will be updated soon to describe the rational more clearly but
it essentially comes to to eliminating conflicts between libraries that
are deployed on the class path with types in the same package as these
modules. It also makes it a little bit easier for EE/application servers
that deploy with the Java EE versions of some of these modules.
Note that these modules have not been removed. The `-addmods` option can
be used to add them to the set of root modules when compiling or running
existing code. For example, code that uses CORBA will compile and run as
before with `-addmods java.corba`. New code that is developed as modules
will use the `requires` clause to declare the dependency, no special
command line option needed.
In summary, this is a case where one policy doesn't suit all. The
proposal is to run with this policy for a period and then re-evaluate
once we have a better idea as to how many applications rely on JDK
versions of these modules.
More information about the jdk9-dev