java.corba and EE modules not resolved by default

[Alan Bateman]

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 [1].

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:

     java.activation
     java.annotations.common
     java.corba
     java.transaction
     java.xml.bind
     java.xml.ws

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.

-Alan

[1] http://openjdk.java.net/jeps/261