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.
-Alan.
