[jsr294-modularity-eg] Capturing dependency information

[Eugene Vigdorchik]

Alex and Andreas,

Do you really think we should leave the decision on what annotations are used to describe dependency relation to deployment
framework vendors?
While I see java is not able to handle all the dependency kinds of all the frameworks, I think that if we envision those frameworks
would provide the annotations,
It seems a good idea to standardize on them in advance. Otherwise we should probably discourage those annotations at all or we are
going to end up with a mess of deployment solutions
penetrating to compile-time also... 

Or is it better to be addressed by JSR-277?

Eugene.

> -----Original Message-----
> From: jsr294-modularity-eg-bounces at cs.oswego.edu 
> [mailto:jsr294-modularity-eg-bounces at cs.oswego.edu] On Behalf 
> Of Andreas Sterbenz
> Sent: Wednesday, June 27, 2007 11:18 AM
> To: JSR 294 Expert Group
> Subject: [jsr294-modularity-eg] Capturing dependency information
> 
> 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.
> _______________________________________________
> jsr294-modularity-eg mailing list
> jsr294-modularity-eg at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/jsr294-modularity-eg
>