[jsr294-modularity-eg] Capturing dependency information

[Andreas Sterbenz]

Experts,

as you are aware, most deployment module solutions (JSR 277, OSGi, etc.) 
have a concept of dependencies between modules. The runtime of the module 
system then uses this dependency information in various ways, for example 
to ensure dependencies are present and that class loaders are setup 
appropriately.

It has been suggested that some concept of dependencies should be 
supported at the Java language level by superpackages. In other words, a 
superpackage could include one or more "depend X" declarations. Let us 
examine that hypothetical declaration in more detail.

The first question is what we want the semantics of this construct to be 
at the language level. We believe the only reasonable answer is that the 
semantics should be identical (or at least very close) to the runtime 
semantics assigned to it by the deployment module system. Otherwise, we 
have the language (javac) tell the developer one thing and the runtime 
something else, which would be counter productive.

However, this is difficult because the dependency declarations in 
deployment module systems are varied and sometimes complicated. They 
include dependencies on superpackages (JSR 277 module system), packages 
and bundles (OSGi), often with additional semantics ("optional", 
"re-export", "uses", etc.). New versions of a module system or future 
module systems may introduce additional requirements. Specifying all of 
this (or some approximation of it) as part of the Java language seems 
neither practical nor desirable.

An alternative to having language level "depend" declarations is to 
declare the dependencies as metadata using annotations. For example, JSR 
277 could declare an annotation "@Import(String moduleName, String 
versionConstraint)" that can be applied to the superpackage. Other module 
systems could declare their own annotations that fit their dependency 
specifications.

Such annotations have no semantics at the Java language level, but they 
can still be interpreted at development time, for example by a wrapper 
around the Java compiler and/or an appropriate annotation processor. This 
could achieve the desired behavior, such as locating the JAR/JAM files of 
the dependencies and giving an error when classes other than those 
explicitly imported are referenced.

Given this, we believe that we can achieve a better and more complete 
solution by going with this annotation based solution. That means there 
would not be dependency declarations for superpackages defined by JSR 294.

Let us know if you have any comments.

Alex and Andreas.