[jsr294-modularity-eg] Expressing module dependencies
Alex.Buckley at Sun.COM
Mon Apr 13 19:28:51 EDT 2009
Peter Kriens wrote:
> Hmm, I think the following does not look too bad for me as a replacement
> or the OSGi manifest:
> 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"
> 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').
jsr294-modularity-eg mailing list
jsr294-modularity-eg at cs.oswego.edu
More information about the jsr294-modularity-observer