annotations
Peter Kriens
peter.kriens at aqute.biz
Fri Apr 17 07:49:27 EDT 2009
That was too quick ...
If javac compiles, it must make its available module systems available
on the classpath, which provides the annotation classes. This will
work fine then and it is a good dependency check.
Kind regards,
Peter Kriens
On 15 apr 2009, at 21:45, Alex Buckley wrote:
> Jesse Glick wrote:
>> A third possibility is to do a bit more parsing inside the
>> annotation values:
>> @Requires({"com.foo.bar >= 4.0", "com.foo.baz >= 5.0"})
>
> My initial mail of examples already had that, i.e.
>
> @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;
>
>> An annotation processor can reject syntactically malformed values
>> with a descriptive message, so this need not be any laxer. (Put the
>> processor in the same JAR as the annotation itself and register it
>> in META-INF/services/javax.annotation.processing.Processor so that
>> it is run automatically by javac.)
>
> Now you hit Evan's chicken-and-egg problem. javac has to find that
> JAR, yet the modules on which the module depends are not yet read.
> Is the answer to put the JAR on the bootclasspath? Maybe, but that's
> likely to be subsumed by bootmodulepath. You're essentially asking
> for annotation processors to enjoy different visibility rules than
> annotated classes, and it's not clear how to do this.
>
> Alex
More information about the jsr294-modularity-observer
mailing list