[jsr294-modularity-eg] Requirements for modules in the Java language

Bryan Atsatt bryan.atsatt at oracle.com
Tue Jan 27 13:47:29 EST 2009


 > 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
> previously.
>
> 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.
>
>
> Alex
> _______________________________________________
> jsr294-modularity-eg mailing list
> jsr294-modularity-eg at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/jsr294-modularity-eg
>


More information about the jsr294-modularity-eg mailing list