Why can modules not be annotated?

Peter Kriens peter.kriens at aqute.biz
Mon Oct 12 16:56:06 UTC 2015


I understand the trade offs. 

That said, I am a bit curious how we are going to handle the discussing these trade offs in the design? I had actually expected that more things were set in stone but in this discussion it seems there are still some open areas. Are we going to have phone conferences, a face to face?

Anyway, thanks for all the responses. It did clarify things for me.

Kind regards,

	Peter Kriens


> On 5 okt. 2015, at 20:49, mark.reinhold at oracle.com wrote:
> 
> 2015/9/28 9:44 -0700, peter.kriens at aqute.biz:
>> In [lang-vm][1] I found:
>> 
>> 	‘A module declaration may not be annotated.’
>> 
>> I was surprised that modules (and their clauses) could not be
>> annotated like package-info.java. Since the source syntax is not
>> extensible, annotations could have been used to provide meta data for
>> other module systems. This would mitigate some of the concerns of
>> using a binary file to encode the module data.
> 
> We haven't seen a compelling use case (so far) for annotations on module
> declarations, or on clauses in module declarations, and they aren't a
> documented requirement, so for simplicity we left them out of the initial
> design and the prototype.
> 
> Supporting annotations on module declarations is technically feasible
> but would add significant complexity to both the specification and its
> implementations.  The machinery to support annotations is everywhere, in
> javac, the VM, core reflection, the language-model API, etc.  Annotations
> in module declarations would also lead to a natural desire for import
> statements in module declarations, further complicating matters.
> 
> Annotations are, fundamentally, a way to make extra-linguistic statements
> in source code that are carried through the tool chain and (usually) into
> the resulting class file.  Beyond the essential linguistic constructs
> already in source-level module declarations (requires, exports, provides,
> and uses), all the other examples we've seen of information that could
> make sense in the resulting module-descriptor class files don't really
> make sense in source code, so annotations aren't the right tool for the
> problem.  Version strings, copyright/license notices, project URLs,
> maintainer contact information, and target operating systems and
> processor architectures, e.g., are more appropriately maintained in build
> metadata (e.g., pom.xml), or calculated by the build system on-the-fly,
> than expressed in source code, and they can easily be added as custom
> attributes to a module-info.class file after it's compiled.
> 
> (Whether it's actually a good idea to put all these sorts of information
> in a module descriptor is a different question.)
> 
> So yes, we could support annotations on module declarations, and that may
> indeed be useful for other module systems.  It would come at significant
> cost, however, and we'd have to weigh that cost carefully.
> 
> - Mark



More information about the jpms-spec-experts mailing list