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

[BJ Hargrave]

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
> 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.

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 
decisions.

> 
> 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.

Why?

> 
> 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 
decision.

> 
> 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 
above.

> 
> 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.
> 

-- 

BJ Hargrave
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...
URL: <http://cs.oswego.edu/pipermail/jsr294-modularity-eg/attachments/20090218/b4c1137d/attachment.html>