[jsr294-modularity-eg] Requirements for modules in the Java language
hargrave at us.ibm.com
Wed Feb 18 08:23:31 EST 2009
I am now going to try and play catch up. Sorry for my tardy replies, but I
was consumed by other things.
Here are my comments on the requirements Alex provided.
jsr294-modularity-eg-bounces at cs.oswego.edu wrote on 2009/01/26 23:41:17:
> 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.
I think artifact is a poor word choice here. It would be much better to
say "A type so modified...". The artifact (JAR, bundle, WAR, ...) is
outside the language spec.
> 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.
Packages don't really exist at runtime. They are a naming construct on
types. But strangely, package names play into package private access
decisions (along with classloaders). Perhaps this requirement and the next
should state that package names are not relevant to module access
> 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.
This is a property of a module system (aliasing, etc). Not of the
language. There is no need for multiple identities to make a module access
> 8. A module must be able to restrict which other modules can declare a
> dependency on it.
This is friends and will be a brittle disaster. One of the main values of
modularity and encapsulation is being able to reason about modules
independently of other modules. Once a module declares who can use it, you
increase coupling tremendously. You cannot replace the consumers of the
module (for cost, performance, M&A, etc.) without changing the consumed
module. While that may be acceptable for closed systems where one has all
the source code, it does not work in the real world where people integrate
code from many suppliers (open source, vendors, in-house).
If a module system wants to allow friends, then that is fine, but it
certainly should not be in the language.
> 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.
This also is a property of a module system. Not the language. This
requirement does not fall from the problems to address or principles
> 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.
Same as above.
> 11. It must be possible for a module's dependency on another module to
> be marked as optional.
Same as above.
> 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.
There is a whole discussion on module identity vs. equality in other mails
upon which I will comment.
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargrave at us.ibm.com
office: +1 386 848 1781
mobile: +1 386 848 3788
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the jsr294-modularity-eg