Scopes in the Jigsaw module system
Jaroslav Tulach
jaroslav.tulach at oracle.com
Fri Aug 17 23:05:24 PDT 2012
Dne Pá 17. srpna 2012 12:23:03, Alex Buckley napsal(a):
> I have added a page to the Jigsaw project which explains our recent
> thinking on "scopes", a mechanism to control the phases in which module
> dependencies must be resolved.
>
> http://openjdk.java.net/projects/jigsaw/doc/topics/scopes.html
>
> Comments welcome.
Hello Alex,
nice. This addresses majority of the issues we run into recently.
I like the "reflection" scope - it directly names the intent of what people are
about to do with such dependency most often - e.g. use Class.forName.
As an unimportant contribution to the terminology dispute, here is my 2Kč
vote: I like "reflection" more than "optional execution", for the reason stated
in previous paragraph. Moreover I have a feeling that a more direct
description for "execution" scope would be "linkage" - e.g. directly express
that the intention of this scope is to prevent LinkageErrors.
It is true that "requires M for execution" is sort of weird (this kind of
dependency should rather be handled by "requires service" imho), but for
people who want to do Class.forName(...) and be sure it always succeeds it may
be useful.
Btw. it is nice how symmetrical the scope system is!
I am glad there is a paragraph about Annotation processors, but I will need
some clarifications. I see following sentence:
> That said, the proper way to view an annotation processor is as a standalone
> module which has a) a main class that implements
> javax.annotation.processing.Processor and b) its own dependencies, some of
> which may be optional.
If I interpret it correctly, you suggest to package the processor into
independent module, separated from the module hosting the annotation. Good,
that is how it should be! Annotation processors usually have much wider set of
dependencies (including I/O, javax.processing, etc.) and mixing them with the
module that provides the API with source time annotation would needlessly
increase the weight of such module (weight being a number of outgoing
transitive dependencies; even conditional).
However how do we guarantee that a source only annotation is properly
processed whenever somebody compiles against the API?
Imagine that java.beans module provides @GenerateBeanInfo annotation to be
placed on any JavaBean class and generate appropriate BeanInfo class
automatically rather than requiring it to be code manually. If I correctly
understood, the associated GenerateBeanInfoProcessor should be placed in a
separate java.beans.processor module. How will the javac know that whenever
somebody uses @GenerateBeanInfo annotation in own code the
java.beans.processor module must be consulted during compilation?
-jt
More information about the jigsaw-dev
mailing list