Interoperation (Was: Re: Module-system requirements)

[mark.reinhold at oracle.com]

2015/3/17 6:46 -0700, david.lloyd at redhat.com:
> On 03/16/2015 03:43 PM, mark.reinhold at oracle.com wrote:
>> 2015/3/11 6:14 -0700, david.lloyd at redhat.com:
>>> On 03/09/2015 03:54 PM, mark.reinhold at oracle.com wrote:
>>>> 2015/2/16 5:57 -0800, david.lloyd at redhat.com:
>>>>> ...
>>>>> 
>>>>> In the case of both Java EE and OSGi, I think it's safe to say that you
>>>>> need to apply a strict 1:1 mapping between modules and class loaders for
>>>>> this to work.
>>>> 
>>>> I don't think we can mandate this.  To divide the SE platform into
>>>> modules in a compatible way requires the ability to load multiple modules
>>>> via the same class loader, so as to respect long-standing assumptions
>>>> about which platform classes are loaded by the built-in class loaders
>>>> (i.e., the bootstrap and extension loaders).  In an early Jigsaw
>>>> prototype we tried the 1:1 module/loader mapping for platform modules
>>>> and found it unworkable from a compatibility perspective.
>> 
>> ...
>> 
>> Perhaps the biggest issue we ran into is that there's lots of code, both
>> in the JDK and out in the wild, that does tests of the form
>> 
>> if (ob.getClass().getClassLoader() == null) { ... }
>> 
>> which, of course, succeeds for classes loaded by the bootstrap loader.
>> 
>> ...
> 
> So it sounds like there is a more concrete underlying requirement here:
> 
> - Define a set of "bootstrap modules" that must all return null for 
> getClassLoader()
> - Using ClassLoader.getSystemResource*(*) and Class.forName(*,*,null) 
> must search all "bootstrap modules"
> - The "java.base" module must be loaded from the bootstrap class loader 
> for implementation reasons
> - "Bootstrap modules" need not actually be loaded by the bootstrap CL if 
> the above requirements are met
> 
> ...
> 
> IOW I don't think that the above constraints alone actually mandate a 
> relationship *or* a lack of relationship between modules and class loaders.

Agreed -- they merely suggest the latter approach.

There are additional considerations which I could describe here, but I
fear we're falling into a morass of design issues when we're still trying
to nail down the requirements.  We already have a requirement to enable
"Compatible Java Platform modularization".  Whether that requirement
mandates a design in which multiple modules can be loaded by a single
class loader is, I suggest, an issue we can discuss later on.

>>> ...
>>> 
>>> Note that in the EE spec, the term "component" has a finer granularity
>>> than "module", i.e. there are 1..N components per module, whereas an
>>> "application" can contain 1 or more modules.
>> 
>> Yes, and I don't think that the module concept we're discussing here will
>> wind up corresponding exactly to what EE calls "modules".
> 
> The two above statements, taken together, don't really exclude class 
> loader per module.

Nor do they mandate that approach.

> ...
> 
>>>> I suggest the module system be as neutral as possible with respect to how
>>>> modules and class loaders are related.  A complex application should be
>>>> able to spin up a class loader for every module it loads, if needed
>>>> (excepting non-upgradeable platform classes), but not all applications
>>>> should be forced to do so.
>>>> 
>>>> New requirement, for the Dynamic Configuration section:
>>>> 
>>>> - _Control of class loaders_ --- An application that loads a module
>>>> into a dynamic configuration must be able to specify the class loader
>>>> to be used to load that module.  That loader need not be the same as
>>>> the loader used to load any other module in the configuration.
>>> 
>>> This goes part of the way, for sure.  I'm not 100% sold yet though.
>>> It's not easy to let go of something that (from our perspective) is
>>> tried and true.
>> 
>> This requirement allows you to use the 1:1 model above SE itself, if you
>> want that, but it doesn't force everyone else to do so.
> 
> I just wonder how much difference there really is between composing 
> single modules out of multiple collections of classes and resources (as 
> we do), versus composing single class loaders out of modules (as you 
> propose).  Given the *high* amount of conceptual overlap between modules 
> and class loaders, I'm still inclined to reject the idea that we need 
> another layer there based on the requirements put forth.

As things stand, we've identified a requirement (quoted above) that
sophisticated applications must be able to control how modules are
associated with class loaders.

I haven't seen a compelling reason to adopt a further requirement that
every module must be loaded by a unique class loader, which seems to be
what you're suggesting.  The fact that some module systems already do
that isn't really relevant, from a requirements perspective, though why
and how they do that will no doubt be of interest in our design
discussions later on.

- Mark