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