[jsr294-modularity-eg] dependency declaration syntax...

[Bryan Atsatt]

We have now discussed a number of options for keyword (requires, 
provides, etc.) operand syntax:

    requires <operand>;

I thought I'd try to enumerate the options so far...

1. Opaque string:

    requires foo at 1.3;

2. Granularity + opaque string:

    requires module foo at 1.3;

3. Granularity + unbounded key/value strings:

    requires package name=bar, version=1.1, vendor=acme;

4. Granularity + bounded, typed key/value pairs (annotation using 
lowercase and without leading "@"):

    requires package(name=bar, version=1.1); // Really @package.


(We also discussed an "unbounded, typed key/value pairs" variant, 
re-using just the annotation style syntax, but... Without a type 
declaration mechanism, we would be in the inference business; I don't 
think we want/need to take that step).


For each operand type, we need to consider how it would be reified in a 
ModuleInfo class. I expect that for each keyword, we will need a method 
that returns a Set<T>, where T is the operand type, e.g.

    public Set<String> getRequires();

for the opaque string case (1). For cases 2 and 3, we would need to 
create a new descriptor type to wrap the granularity and the string or 
key/value strings. Case 4 seems to require a return type of Object, 
necessitating a downcast.


I believe one constraint on the design space here is that a key/value 
syntax needs to be unbounded: OSGi supports arbitrary attributes on 
dependency declarations. This would imply a hack in the annotations case 
(e.g. name=bar, version=1.1, attributes="key1=value1, ...").

And while I do like the idea that annotations provide an easily consumed 
grammar, the extra complexity here does not seem worth it (even aside 
from Alex's concerns about compiler difficulties).

So far, I think 3 provides the best balance of 
functionality/clarity/simplicity/extensibility.

// Bryan