[jsr294-modularity-eg] 294 EG conf call, 2009-03-18

[Alex Buckley]

// EG members, feel free to add/edit points I haven't noted correctly.


* Attendees

Alex Buckley, Bryan Atsatt, Richard Hall,
  BJ Hargrave, Peter Kriens, Michal Cierniak
Apologies: Daniel Leuck


* Mapping modules to classloaders

The bulk of the discussion was the pros and cons of these options:

1) a runtime module can span classloaders, so multiple deployment 
modules (JARs) can contribute to the same runtime module and each 
classloader-worth of a runtime module can have its own lifecycle;  or

2) a runtime module cannot span classloaders, but the VM consults a 
runtime module object to discover who its friends are (various codenames 
for "friend" are used: group access, multi-module access, module group).

BJ stated the benefits of (1) as independent lifecycles for deployment 
modules in the same layer, and that it helps a module system to be able 
to incrementally load a layer's classes without worrying about the 
content of existing classloaders. Peter stated that this model works for 
'hello world' apps and also large enterprise apps, which is desirable.

Bryan stated the problems of (1) as classes in the same runtime module 
but different classloaders (due to different OSGi bundles) not seeing 
the same metadata (except for name and version). "Implied visibility" 
within a module is broken. This complicates an API which exposes details 
of a runtime module (needs to be indexed by defining classloader) and 
ultimately allows a runtime module to have multiple types with the same 
name and different definitions simultaneously.

In OSGi, 'module' would be a new concept and bundles would have an n:1 
relationship to modules. Bryan feels it would be awkward not to have a 
1:1 relationship between deployment modules and runtime modules. BJ 
points out that fragments already have n:1 relationship between 
deployment artifacts (bundles) and the runtime artifact (classloader).

BJ stated that one concept:
   runtime module (across classloaders)
is more lightweight than two:
   runtime module (within a classloader) + module group

Bryan proposed disallowing a runtime module to span classloaders, but 
allowing nesting of runtime modules within a classloader, via a 
hasModuleAccess(Module) callback to the module system from the VM.


* Face-to-face meeting before EclipseCon in March

Monday 23 March, 9am-evening, at Sun's Santa Clara campus.

- Requirements for sharing, accessibility, and visibility
- Module:classloader mapping
- Module-system-specific dependencies / opaque dependencies in source
- Compile-time use of a module system

Alex