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