[jsr294-modularity-eg] Requirements for modules in the Java language
Alex.Buckley at Sun.COM
Mon Jan 26 23:41:17 EST 2009
* Principles of modules in the Java language
JSR 294 introduces the notion of "module" to solve the problems listed
A module is a named set of packages that a) defines an encapsulation
boundary for its member types, b) describes its relationships with other
named modules, and c) enforces both encapsulation and relationships at
compile-time and runtime. A module is identified by a name and
optionally a version.
Modules are part of the language to be delivered in the Java SE 7
platform, so can assume the use of an SE 7-compliant compiler, JVM, and
ClassFile format. In the SE 7 platform, a Java compiler cooperates with
a module system to enforce encapsulation and relationships at
compile-time. A JVM cooperates with a module system to enforce
encapsulation and relationships at runtime.
* Requirements for modules in the Java language
1. A module-private modifier for access control must be supported for
classes, interfaces, and their members. An artifact so modified can only
be accessed from types in the same module as the artifact.
2. It must be possible for the Java language to compute the module to
which a type belongs, to enforce access control.
3. It must be possible for types in different packages to belong to the
4. It must be possible for different types in a single Java package to
belong to different modules.
5. A module must be declared in a form which allows annotations to be
placed on it.
6. A module must be able to declare dependencies on other modules, by
specifying their identities in the Java language. The effect of a module
M declaring a dependency on module N, where N does not otherwise
restrict M's dependency, must be to make the public types of N
observable at compile-time and runtime to all types in M.
7. A module must be able to declare multiple identities by which it may
satisfy another module's dependency.
8. A module must be able to restrict which other modules can declare a
dependency on it.
9. It must be possible for a module's dependency on another module to be
marked such that observable public types in the latter are "re-exported"
by the former. That is, if module L depends on module M, and module M
depends on module N, then M must be able to specify whether the
observable types of N are observable to L.
10. It must be possible for a module's dependency on another module to
be marked such that the same defining classloader is used for all types
in both modules.
11. It must be possible for a module's dependency on another module to
be marked as optional.
12. It must be possible for unit and regression tests outside a module
to access module-private artifacts within the module.
13. The Java language must not directly use the value of the version in
a module's identity, but may rely on the presence or absence of a
version in a module's identity.
jsr294-modularity-eg mailing list
jsr294-modularity-eg at cs.oswego.edu
More information about the jsr294-modularity-observer