[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-jigsaw-dev
Subject:    Use cases for multi-module packages in the JDK
From:       mandy.chung () oracle ! com (Mandy Chung)
Date:       2011-02-15 20:06:11
Message-ID: 4D5ADCB3.2070301 () oracle ! com
[Download RAW message or body]

  On 02/15/11 09:29, David M. Lloyd wrote:
> 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 document above is intended to report my analysis of the JDK so that 
the data can be used to decide if multi-module package support is a 
requirement to the Java module system.  Thus it didn't cover the design 
and considerations (which is out of the scope).

> 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()
>

If a module system allows splitting a package across multiple modules, 
this would be an issue if the above statement is true.

I can share some details how the current design and implementation of 
jigsaw addresses that.

The current design in jigsaw requires that multiple modules defining 
types in the same package must be loaded by the same class loader.   The 
local dependence [1] (i.e. the 'local' modifier) is specifically 
designed for this use so that the client module can declare a local 
dependence on the base module:

    module client {
        requires local base;
    }

In this case, the jigsaw module system will assign the base and client 
modules in the same context (during the module configuration process) so 
that they all wind up in the same class loader at run time.  See more at:
    
http://cr.openjdk.java.net/~mr/jigsaw/api/org/openjdk/jigsaw/Configurator.html

> 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).

For the JDK classes, they are loaded by null class loader (e.g. 
System.class.getClassLoader() == null).  Regardless of whether a package 
is allowed to be split across multiple modules or not, as for backward 
compatibility, getClassLoader() possibly needs to return null for JDK 
classes in the modular world.

[1]   http://openjdk.java.net/projects/jigsaw/doc/language.html

[prev in list] [next in list] [prev in thread] [next in thread]