[jsr294-modularity-eg] Expressing module dependencies

[Peter Kriens]

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;

I am not giving up my resistance against the whole idea of encoding  
the class path in the language, it is still a bit too much Alice in  
Wonderland. However, I do not think that the lack of syntactic sugar  
in annotations is even remotely comparable to the danger of encoding   
a practice in the language that will look very silly in the next few  
years. 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.

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

Kind regards,

	Peter Kriens



On 9 apr 2009, at 03:32, Alex Buckley wrote:

> In the putative 294 spec, a module compilation unit ("module-info")
> defines a module's name, version, and dependencies. The EG has  
> expressed interest in what dependencies look like as annotations v.  
> as keywords, so here are some examples of what is possible  
> syntactically.
>
> Bear in mind that non-JLS annotation types must be imported. The JLS  
> changes already allow 'import' statements before a module  
> declaration for this reason.
>
>
> 1) Annotations
>
> @Requires("com.foo.bar @ 4.0+")
> module com.foo.app @ 1.0;
>
> @Requires(module="com.foo.bar", version=">=4.0")
> module com.foo.app @ 1.0;
>
> @Requires(package="com.foo.bar", version=">=4.0", uses="com.foo.bar")
> module com.foo.app @ 1.0;
>
> @Requires(package="com.foo.bar", attributes="friend:yes")
> module com.foo.app;
>
> JSR 175 decided not to allow multiple annotations of the same name  
> on the same element. That decision might be changed one day, but 294  
> is not the place to change it. Multiple dependencies must be encoded  
> somehow:
>
> @Requires({ "com.foo.bar @ 4.0+", "com.foo.baz @ 5.0+" })
> module com.foo.app @ 1.0;
>
> @Requires({ "com.foo.bar", "com.foo.baz" }, { ">=4.0", ">=5.0" })
> module com.foo.app @ 1.0;
>
> @RequiresContainer({
>  @Requires(module="com.foo.bar", version=">=4.0"),
>  @Requires(module="com.foo.baz", version=">=5.0")
> })
> module com.foo.app @ 1.0;
>
> @Requires({ "com.foo.bar @ 4.0+" })
> @RequiresOptional({ "com.foo.baz @ 5.0+", "com.quux.nab @ 6.0+" })
> module com.foo.app @ 1.0;
>
> import org.osgi.annotations.*;
> @RequireBundles({ "com.foo.bar @ [4.0,5.0)" })
> @ImportPackages({ "com.foo.baz @ [5.0,6.0)", "com.quux.nab @ 6.0" })
> module com.foo.app @ 1.0;
>
> Dependencies have many facets - the kind of target, optionality,  
> constraints (OSGi's "uses") - and it looks like every combination  
> would require its own annotation type ... or else define one common  
> annotation type with many fields that will often be empty.
>
> Note that imported annotation types implicitly indicate which module  
> system a dependency is for. Other module systems just ignore  
> annotations not of their own annotation types.
>
> Having said that, at least one standard annotation type for  
> dependencies will have to be defined in the JLS, to be understood by  
> a compiler which isn't using any module system.
>
>
> 2) Keywords
>
> module com.foo.app @ 1.2 {
>  requires com.foo.bar @ 4.0+, com.foo.baz @ 5.0+;
>  requires optional com.quux.nab @ 6.0+;
> }
>
> And using the "free" grammar which allows arbitrary terms after  
> 'requires', plus a convention that a dependency specific to a module  
> system is identified by the first term:
>
> module com.foo.app @ 1.2 {
>  requires osgi optional dynamic package com.quux.nab @ [1.0,2.0);
> }
>
>
> Annotations play the role of metadata in Java programs; they should  
> not affect the meaning of programs. They are extra-lingual - outside  
> the language. Most people who want to expand the Java language with  
> new features cannot do so, so express their features outside the  
> language via annotations.
>
> The EG is not so limited. The aim of JSR 294 is to make modular  
> programming easier *in the Java language*. Not via XML files, not  
> via tools, but with language constructs. We can expand the language  
> to include the concept of a dependency, expressed via 'requires',  
> even if some aspects of a dependency are not controlled by the  
> language. The rubber (language) has to meet the road (module system)  
> somewhere.
>
> By way of analogy, Java would be better if the @Override annotation  
> was a restricted keyword 'override' which acted as a method modifier.
>
> Alex
> _______________________________________________
> jsr294-modularity-eg mailing list
> jsr294-modularity-eg at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/jsr294-modularity-eg

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/jsr294-modularity-eg/attachments/20090410/8e60c50e/attachment.html>