[jsr294-modularity-eg] Expressing module dependencies

Richard S. Hall heavy at sun.com
Mon Apr 13 22:47:15 EDT 2009


On 4/13/09 7:28 PM, Alex Buckley wrote:
> 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.

I was under the impression that "permits" was some form of poor man's 
security, not a way of specifying provider compatibility ranges. In 
other words, I though it was "I permit these other modules to see me."

Perhaps you could explain it further, but I don't see how listing 
specific "permitted" modules relates to "provider determines compatibility".

-> richard
>
> Also there is the entrypoint of a module (the 'class' keyword suffices 
> for that) and the aliases of a module ('provides').
>
> Alex
> _______________________________________________
> jsr294-modularity-eg mailing list
> jsr294-modularity-eg at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/jsr294-modularity-eg


More information about the jsr294-modularity-eg mailing list