[jsr294-modularity-eg] Expressing module dependencies
Alex.Buckley at Sun.COM
Tue Apr 14 15:47:22 EDT 2009
Peter Kriens wrote:
>> What is @Bundle?
> An annotation ... :-) What else?
>> What is @Jigsaw? You're missing some import statements, unless you're
>> proposing that these annotation types are handled specially in the JLS
>> and javac's name interpretation logic. At that point, they're
>> basically keywords.
> Nope, they are standard annotations, I tested it.
I don't understand. Of course Bundle and Jigsaw are annotation types but
what package are they declared in? How come you're not importing it?
>>> Java had to change the meaning of volatile several times before they
>>> got it right, I am pretty confident a require will a similar fate
>>> because a lot of things are happening in this area, both in research
>>> and with practioners.
>> Please identify these things so JSR 294 can be better informed.
> I think I already did in a previous mail.
The "Why Require is Considered Harmful" mail? That didn't mention
anything happening in research. It mentioned .NET but I have no idea how
.NET attributes are processed or if it's similar to how Java compilers
process annotations. (I'd guess the answer is "not very similar".)
I ask again: what is happening in research and practice around
dependencies that you think JSR 294 should be aware of?
>>> Anyway, I also expect that any module will need more directives than
>>> just require. Will we encode those in language constructs as well?
>> The tentative 294 spec published in early February had a 'permits'
>> keyword too. If modules A and B are nodes in a directed graph, then
>> 'requires' is an edge from A to B, while 'permits' is an edge from B
>> to A. There is no mystery about the need for "reverse" dependencies as
>> expressed by 'permits' - it's an encoding of the "provider determines
>> compatibility" idea we discussed at the EclipseCon BOF.
> But you do not think you need information like a readable (localizable)
> name, a description, copyright info, etc? Where will you store those?
I think a requirement to store this kind of metadata is already
represented by the requirement to be able to annotate a module
declaration. A module system can create its own annotation types for
such metadata and interpret annotations at compile-time or runtime as it
Dependencies are not metadata. They are a crucial part of the module's
data, along with its classes. I mentioned in the previous mail that
annotations for dependencies would need so much special treatment that
they'd be logically equivalent to keywords. I don't plan to make a slide
deck on the ins and outs of annotation processing to prove that, sorry.
'requires' and 'permits' are essential parts of JSR 294 to Sun, and I
would ask you to respect that. As spec lead, Sun has diligently
responded to Expert Group concerns: by allowing runtime modules to span
classloaders, by allowing inference rather than declaration of module
membership at compile-time and runtime, by extending interfaces to allow
module-private members, and by allowing the 'package' keyword as a modifier.
More information about the jsr294-modularity-eg