[jsr294-modularity-eg] Expressing module dependencies

[Alex Buckley]

Peter Kriens wrote:
> Hmm, I think the following does not look too bad for me as a replacement 
> or the OSGi manifest:
> 
> @Bundle(
>         require_bundle      = "com.acme.foo; version='[2.1,3)',"
>                             + "com.acme.foo2,"
>                             + "com.aQute.bndlib; version='2.1'",
>         bundle_symbolicname = "biz.aQute.bnd",
>         bundle_name         = "Bnd Annotations",
>         bundle_description  = "Provides annotations to OSGi bundles",
>         bundle_docurl       = "http://www.aQute.biz",
>         bundle_copyright    = "Copyright aQute SARL (c) 2002-2009"
> )
> @Jigsaw(
>   ...
> )
> module aQute.bnd.annotation;

What is @Bundle? What is @Jigsaw? You're missing some import statements, 
unless you're proposing that these annotation types are handled 
specially in the JLS and javac's name interpretation logic. At that 
point, they're basically keywords.

> Java had to change the meaning of volatile several times before 
> they got it right, I am pretty confident a require will a similar fate 
> because a lot of things are happening in this area, both in research and 
> with practioners.

Please identify these things so JSR 294 can be better informed.

> Anyway, I also expect that any module will need more directives than 
> just require. Will we encode those in language constructs as well?

The tentative 294 spec published in early February had a 'permits' 
keyword too. If modules A and B are nodes in a directed graph, then 
'requires' is an edge from A to B, while 'permits' is an edge from B to 
A. There is no mystery about the need for "reverse" dependencies as 
expressed by 'permits' - it's an encoding of the "provider determines 
compatibility" idea we discussed at the EclipseCon BOF.

Also there is the entrypoint of a module (the 'class' keyword suffices 
for that) and the aliases of a module ('provides').

Alex