[jsr294-modularity-eg] Expressing module dependencies

[Alex Buckley]

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

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.

Alex