[jsr294-modularity-eg] 294 EG F2F meeting, 2009-03-23
Alex.Buckley at Sun.COM
Tue Mar 31 16:41:57 EDT 2009
// EG members, feel free to add/edit points I haven't noted correctly.
Alex Buckley, Bryan Atsatt, Richard Hall, BJ Hargrave, Peter Kriens,
Sam Pullara, Bob Lee (standing in for Michal Cierniak; Bob has now
joined the EG as a second Google representative)
Apologies: Daniel Leuck
* Module grouping
Bryan phrased a key requirement (supported by most EG members) as:
multiple modules can cooperate using types not available to outsiders.
This means multiple modules can ACCESS each others' types which remain
INACCESSIBLE from other modules. A module system would necessarily have
to make the types visible across modules as well.
BJ blogged an excellent summary of visibility v. accessibility:
The meeting decided to stay with 'runtime module' as the sole mechanism
by which a module system can group multiple modules.
The meeting decided not to adopt a 'module scope' concept, or module
nesting, for grouping multiple modules.
Access control can implicitly be deferred to the module system by having
the VM call Module.hasModuleAccess(Module m) when computing
accessibility to a module's types. (The receiver is the requested
module.) A Module can return this==m in simple cases, or simulate more
advanced concepts like nesting.
The meeting discussed a permission check allowing a client to use a
classloader to define a class *as a member of a given runtime module*.
However, since the client is likely to be a module system and must
already have permission to get the classloader, a new permission was
seen as low priority.
* Compile-time use of a module system
Most EG members do not support declaring dependencies (i.e. controlling
visibility, also called observability in the JLS) with a keyword in Java
source code. Sam and Bob proposed declaring dependencies with
annotations, though that has bootstrapping issues.
* Next meeting
Wednesday 1 April. 10am US West, 1pm US East.
- Compile-time use of a module system, especially in light of the
OSGi Tool Summit:
jsr294-modularity-eg mailing list
jsr294-modularity-eg at cs.oswego.edu
More information about the jsr294-modularity-observer