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

[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
Apologies: Michal Cierniak


* Mapping modules to classloaders

BJ asked for a new requirement: "It must be possible for types in the 
same module to be defined by different classloaders."

The principle behind this requirement is that an entire layer of a 
software stack can be modelled as a single module. The layer may be 
delivered as multiple artifacts and loaded by multiple classloaders, but 
its internals are encapsulated because its types are in the same logical 
module for access control purposes.

In this model, define a "split module" as one whose types are defined by 
multiple classloaders. A module system is always free to create split 
modules by judicious use of defineClass(..., ModuleId).

The question is whether the JVM should implement module-private access 
control for split modules. Requirement #1 [1] did not envision split 
modules when it said "A module-private modifier for access control must 
be supported for classes, interfaces, and their members. A type/member 
so modified can only be accessed from types in the same module."

The logic of module-privacy for split modules is easy to sketch, but:

- Package-private types in a split package are inaccessible to each 
other. (An anachronism which 294 is not going to change.) It is simple 
and symmetric to say that module-private types in a split module are 
inaccessible to each other.

- The requirement is to split a module across classloaders; it is 
neutral on splitting a package in that module across classloaders. Some 
felt that explicit discouragement of split packages is worthwhile 
because they are a fact of life and will be observable at compile-time 
as well as runtime when javac uses a module system. Without explicit 
discouragement for split packages, there is the surprising fact that a 
type cannot access a package-private type in its own package but can 
access a module-private type in another package:

// This class is defined by classloader CL1
module M;
package P;
class Foo {}

// This class is defined by classloader CL2
module M;
package P;
class Bar {
   new Foo();     // Illegal
   new Q.Quux();  // Legal
}

// This class is defined by classloader CL3
module M;
package Q;
module class Quux {}

When a package cannot guarantee accessibility to its members, but a 
module can guarantee accessibility to ITS members, it is clear that 
module membership (orthogonal to classloaders) is more meaningful than 
package membership (not orthogonal to classloaders. This is inevitable 
given the model of a module as a layer comprising multiple classloaders. 
It does not agree with the model of a module as a component, i.e. a 
versioned entity encapsulating a set of related packages.

In the layer model, the types contributed to a module by multiple 
artifacts need not all observe the same types in other modules. 
Specifically, BJ stated he did not assume that a module's dependencies 
are the union of its artifacts' dependencies.


* Nested modules

Modules spanning classloaders is orthogonal to module nesting. Nesting 
is ultimately realized by the VM deferring part of the module-private 
access control decision to the module system. The desirability of 
nesting remains an open question.

Some questions arose about the "reach" of nesting: Do all modules in a 
nesting hierarchy have the same lifecycle, i.e. are all installed / 
started / stopped / uninstalled as a unit? Does a parent module 
implicitly depend on its children?

General support for letting the module system figure this out, e.g. an 
OSGi container could start a child module ("child" according to some 
OSGi convention) as a fragment of a parent module. Lifecycle is not in 
scope for 294.


* 'requires' keyword

Some support for scoping a 'requires' statement to a module system, so a 
module may be written to work in multiple module systems:

module M @ 1.0 {
   jigsaw requires ...
   osgi   requires ...

   // Or with annotations

   @Jigsaw requires ...
   @OSGi("Bundle-ManifestVersion: 2") requires ...
}

Ultimately, a module can target dependencies against a given module 
system, but it is helpless if that module system is not available to a 
JVM. Many questions arise about which dependencies to resolve if 
multiple module systems are available and targeted by a module. A more 
workable scheme may be to scope the module declaration as a whole:

@OSGi
module M ... { ... }


* Dependencies in source code

Peter did not support declaring dependencies in source at all. Claim: 
having to list dependencies upfront is unnecessarily constraining; 
programmers should have a broad palette of packages available to them 
during development (e.g. for code completion in an IDE); a build-time 
step should determines actual dependencies from classfiles and reify 
those dependencies in the artifact.

The spec lead acknowledged this claim, but module-info.java/class does 
not need to be an input to an IDE; it can be generated by an IDE at any 
time before packaging, based on project-level configuration or actual 
classfile dependencies. javac needs module-info.java/class as an input, 
since it replaces the classpath.


* Action items

Peter to expand the Runtime section in the Nested Modules proposal.
Peter to document objections to dependencies in source.


* Face-to-face meeting at EclipseCon in March

Monday 23 March, 9am-evening, at Sun's Santa Clara campus.
(Moved from 12pm to 9am to enable Richard to attend.)
Large room + breakout room reserved. LAN+wifi available.


* Next meeting

Wednesday 18 March. 10am US West, 1pm US East, 7pm France.
(Not 11 March due to various members' other commitments.)

- Continue discussion of module:classloader mapping.
- Continue discussion of module-system-specific dependencies / opaque 
dependencies in source.
- Discuss BJ's points about what features properly belong in the 
language v. a module system.


Alex

[1]http://altair.cs.oswego.edu/pipermail/jsr294-modularity-eg/2009-January/000187.html
_______________________________________________
jsr294-modularity-eg mailing list
jsr294-modularity-eg at cs.oswego.edu
http://cs.oswego.edu/mailman/listinfo/jsr294-modularity-eg