[jsr294-modularity-eg] Requirements for modules in the Java language
Alex.Buckley at Sun.COM
Tue Jan 27 22:03:53 EST 2009
Yes, splitting a package across multiple modules at compile-time and
runtime is possible in OSGi and will be possible in Jigsaw too.
Whether types in that package are loaded into different classloaders (as
I think Require-Bundle would assure) or the same classloaders (as a
Jigsaw module loader could attempt) is a matter for requirement 10.
(Incidentally, it is difficult for a compiler to check that all source
and classfiles within a package belong to the same module, since a
compiler typically reads the source files it is given plus the
source/classfiles referred to therein, and that's it. Unrelated
source/classfiles that happen to be in a package it's compiling for are
not of concern. So the requirement fits with that.)
Bryan Atsatt wrote:
> > 4. It must be possible for different types in a single Java package to
> > belong to different modules.
> This is in support of OSGi's split-package (via Require-Bundle)? Are
> there other expected use cases?
> // Bryan
> Alex Buckley wrote:
>> Comments welcome.
>> * 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
>> same module.
>> 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
> jsr294-modularity-eg mailing list
> jsr294-modularity-eg at cs.oswego.edu
jsr294-modularity-eg mailing list
jsr294-modularity-eg at cs.oswego.edu
More information about the jsr294-modularity-observer