jsr294-modularity-observer Digest, Vol 14, Issue 7
Evan Cowden
evan38109 at gmail.com
Wed Apr 15 13:53:41 EDT 2009
I've spent some time a while ago creating a set of annotations and
annotation processors to generate OSGi metadata. There are a few
things I learned during the process that I think may be relevant to
the current discussion:
1. Creating a good set of annotations is harder than it looks. Even
with several tries, I was never able to create anything that was
nearly as clean as a plain text file; after a while my teammates all
abandoned the annotations. Most importantly, the no-duplicates
limitation can create very convoluted and difficult to understand
structures. Take a look at Peter's suggestions - they are quite
similar to what I tried first, although mine went on a package-info:
@Requires(module="com.foo.bar", version=">=4.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;
Not only is it a lot of typing, but there are two distinct ways to
express a dependency: the @Requires and the @Requires nested in
@RequiresContainer. It took a bizarrely long amount of time to
explain this to junior developers (and even some senior developers).
Moreover, when one starts with the former, as is often the case,
adding a new dependency requires not just adding another line, but
reformatting what already exists.
I also strongly recommend against the following format for multiple
dependencies, which I tried and found lead to more bugs than I can
count:
@Requires({ "com.foo.bar", "com.foo.baz" }, { ">=4.0", ">=5.0" })
module com.foo.app @ 1.0;
The separation of module names and versions invariably leads to
erronous editing that put the names and versions out of whack.
2. It is significantly trickier to create tooling that manipulates
annotations than a plain text file. For instance, take a look at
tooling like the Eclipse PDE Manifest Editor. Most IDEs will want to
provide something similar for a standard module system. The
annotation syntax is not only more difficult, but you need to maintain
the import statements for the annotations as well. It's not
impossible, but it's not trivial either.
3. What about the extender pattern? With OSGi, it's both easy and
common to stick extra metadata into the manifest. For instance, one
might make a bundle that will deploy servlets in other bundles by
examining all manifests for an ExportServlet attribute. With strongly
typed annotations, there is no room to just add a line with an extra
tag. For this kind of extender, it would be possible for the extender
provider to create their own annotation - that may or may not be an
improvement - but it complicates #4 below.
There is another kind of extension, however, that is even more
difficult. Eclipse Equinox, for instance, also adds extra attributes
to existing elements, for instance:
Export-Package:
org.eclipse.pde.internal.ui;x-internal:=true
The x-internal flag is (correct me if I'm wrong) an Equinox-specific
extension to standard OSGi metadata. It works perfectly fine here,
but how would annotations accommodate it? Do Equinox users need to
use a specialized set of annotations to supplant the standard ones?
With the status quo, a bundle with Equinox-specific information can
still work in another container - the other container will just ignore
the extra bits it doesn't understand. That won't work if Equinox
developers start using custom annotations.
4. Annotations themselves create dependencies. This is, by far, the
trickiest problem I encountered. Since annotations are class files,
they create a binary dependency. Yet when annotations are used to
express dependencies, it creates a chicken-and-egg problem. You need
to resolve the dependency before you can get the information telling
you what dependencies to resolve. The solution is invariably to
bootstrap those annotations at a level below the module system, but if
you ask me, a module system that doesn't work for itself is a sure
sign of a poorly designed module system.
I'm not trying to move the Expert Group towards or away from any one
technology, but I did want to share my experience. I hope that these
observations can help lead to a better specification.
- Evan Cowden
On Wed, Apr 15, 2009 at 11:00 AM,
<jsr294-modularity-observer-request at cs.oswego.edu> wrote:
>
> Send jsr294-modularity-observer mailing list submissions to
> jsr294-modularity-observer at cs.oswego.edu
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://cs.oswego.edu/mailman/listinfo/jsr294-modularity-observer
> or, via email, send a message with subject or body 'help' to
> jsr294-modularity-observer-request at cs.oswego.edu
>
> You can reach the person managing the list at
> jsr294-modularity-observer-owner at cs.oswego.edu
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of jsr294-modularity-observer digest..."
>
>
> Today's Topics:
>
> 1. Re: [jsr294-modularity-eg] Expressing module dependencies
> (Paul Benedict)
> 2. Re: [jsr294-modularity-eg] Expressing module dependencies
> (Peter Kriens)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 15 Apr 2009 00:11:08 -0500
> From: Paul Benedict <pbenedict at apache.org>
> Subject: Re: [jsr294-modularity-eg] Expressing module dependencies
> To: JSR 294 Expert Group Observers
> <jsr294-modularity-observer at cs.oswego.edu>
> Message-ID:
> <b9e663070904142211w34c369a1qdd6e6c61bc1ede09 at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> When seeing annotations upon the module keyword, I think there is even
> a stronger case for avoiding the M at V notation. I did write an email
> about the (confusing) repurposing of the annotation symbol, and how a
> colon should be preferred over @ to specify a module version. I do
> hope the JSR takes that change proposal up for consideration. It is a
> standard convention with Maven, and foreach/switch/labels already use
> the colon to specify "additional" information.
>
> module A : 3.0 {
> permits <requires A : 2.0>;
> }
>
> Paul
>
> On Tue, Apr 14, 2009 at 5:58 PM, Alex Buckley <Alex.Buckley at sun.com> wrote:
> > Alex Buckley wrote:
> >>
> >> Peter Kriens wrote:
> >>>>
> >>>> What is @Bundle?
> >>>
> >>> An annotation ... :-) What else?
> >>>
> >>>> 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.
> >>>
> >>> Nope, they are standard annotations, I tested it.
> >>
> >> I don't understand. Of course Bundle and Jigsaw are annotation types but
> >> what package are they declared in? How come you're not importing it?
> >
> > Hmm, I guess they're in an unnamed package. How are you making their
> > classfiles visible to the compiler? When compiling module-info.java, the
> > only types visible will be those in modules required by that very
> > module-info.java. (Unless Bundle.class and Jigsaw.class are on the
> > bootclasspath and treated specially, which turns them into pseudo-keywords
> > as I've said before.)
> >
> > Alex
>
>
> ------------------------------
>
> Message: 2
> Date: Wed, 15 Apr 2009 08:13:40 +0200
> From: Peter Kriens <peter.kriens at aqute.biz>
> Subject: Re: [jsr294-modularity-eg] Expressing module dependencies
> To: JSR 294 Expert Group <jsr294-modularity-eg at cs.oswego.edu>
> Message-ID: <D9F85351-983C-4650-9B03-047D4E43924F at aQute.biz>
> Content-Type: text/plain; charset="us-ascii"; Format="flowed";
> DelSp="yes"
>
> Ok, now I understand what you meant.
>
> Yes, they can be in the default package, or you could name them:
> @osgi.Config if you dont like that, up to the module system ....
>
> The most important part is that you can create your own syntax and we
> do not have to clutter the Java syntax with Jigsaw specific constructs
> as well have to use an opaque strings with very little syntactic
> difference.
>
> Kind regards,
>
> Peter Kriens
>
>
>
>
>
> On 15 apr 2009, at 00:58, Alex Buckley wrote:
>
> > Alex Buckley wrote:
> >> Peter Kriens wrote:
> >>>> What is @Bundle?
> >>> An annotation ... :-) What else?
> >>>
> >>>> 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.
> >>> Nope, they are standard annotations, I tested it.
> >> I don't understand. Of course Bundle and Jigsaw are annotation
> >> types but what package are they declared in? How come you're not
> >> importing it?
> >
> > Hmm, I guess they're in an unnamed package. How are you making their
> > classfiles visible to the compiler? When compiling module-info.java,
> > the only types visible will be those in modules required by that
> > very module-info.java. (Unless Bundle.class and Jigsaw.class are on
> > the bootclasspath and treated specially, which turns them into
> > pseudo-keywords as I've said before.)
> >
> > Alex
> > _______________________________________________
> > jsr294-modularity-eg mailing list
> > jsr294-modularity-eg at cs.oswego.edu
> > http://cs.oswego.edu/mailman/listinfo/jsr294-modularity-eg
>
> _______________________________________________
> jsr294-modularity-eg mailing list
> jsr294-modularity-eg at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/jsr294-modularity-eg
>
>
> ------------------------------
>
> _______________________________________________
> jsr294-modularity-observer mailing list
> jsr294-modularity-observer at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/jsr294-modularity-observer
>
>
> End of jsr294-modularity-observer Digest, Vol 14, Issue 7
> *********************************************************
More information about the jsr294-modularity-observer
mailing list