Up to date syntax documentation?

Alan Bateman Alan.Bateman at oracle.com
Thu Oct 15 13:16:31 UTC 2015

On 15/10/2015 12:52, Philippe Marschall wrote:
> :
> Most of my needs for optional dependencies come from annotations. 
> Three examples come to mind:
> 1. Lifecycle annotations like (javax.annotation): If code runs within 
> some container often methods with such annotations are detected and 
> automatically invoked at the right time. But if the same code runs 
> outside a container the annotations are not needed and the methods can 
> simply be invoked explicitly.
> 2. Additional type check annotations (eg. JSR-305): These annotations 
> are not needed at runtime but still need to be in the class files for 
> tools to perform static analysis. Generally all annotations with a 
> retention policy of class are candidates for optional dependencies.
> 3. Mapping annotations: Sometimes classes have annotations for 
> specific mapping technologies. But if they are used without these 
> mapping technologies then the annotations are not needed at runtime.
Indeed, annotations are a case they might not be needed at run-time or 
are ignored because the annotation type is not present. In the current 
design/prototype there is no support for optional dependences. That is, 
if you have a dependency on a module that is exporting the packages with 
these annotations then that module needs to be observable at run-time.

It is of course possible to conjure up a command line to compile without 
a declared dependency but I'm not suggesting anyone does that.

Is it worth the complexity? I think not but this is really something for 
the JSR.

> :
> Where in the JAR does this information end up?
It adds an attribute to the module-info.class (so not strictly tied to 
the JAR format, it will work with other formats, even modules exploded 
on the file system if really needed).

If you use jar -p or --print-module-descriptor to print the module 
descriptor when you will see it. If the JAR file is extract then you'll 
see it with javap -v too.


More information about the jigsaw-dev mailing list