[jsr294-modularity-eg] dependency declaration syntax...
bryan.atsatt at oracle.com
Thu Apr 30 15:58:45 EDT 2009
We have now discussed a number of options for keyword (requires,
provides, etc.) operand syntax:
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
jsr294-modularity-eg mailing list
jsr294-modularity-eg at cs.oswego.edu
More information about the jsr294-modularity-observer