Use cases for multi-module packages in the JDK

[David M. Lloyd]

On 02/14/2011 08:43 PM, Mandy Chung wrote:
> This document summarizes the use cases in the JDK that can benefit from
> multi-module package support:
> http://cr.openjdk.java.net/~mchung/jigsaw/analysis/multi-module-package.html
>
>
> It describes how the multi-module package reduces dependency across
> modules and that results in a cleaner modularization of JDK.

The term "multi-module packages" might be a bit misleading.  It could 
and should be possible for more than one module to define a package of 
the same name.  However it seems that each package would have to have 
its own seal base, Package instance (tied to its module's ClassLoader), 
etc.  There really is no sensible alternative that I can see.  And this 
means that, by your proposed changes, the following statement is true:

java.beans.ConstructorProperties.class.getPackage() != 
java.beans.BeanInfo.class.getPackage()

to pick a random other class from that package.  Assuming that this is 
OK, then the changes seem a bit ugly but reasonable.  But note that this 
is a change which could affect backwards compatibility (though it could 
be argued that it might already be surprising enough that JDK classes 
would now come from multiple class loaders).
-- 
- DML