[jsr294-modularity-eg] Ignoring unknown directives...

[Bryan Atsatt]

Bob Lee wrote:
> On Wed, Jun 24, 2009 at 1:40 PM, Bryan Atsatt <bryan.atsatt at oracle.com 
> <mailto:bryan.atsatt at oracle.com>> wrote:
>
>     We are talking about locating a single implementation object (i.e.
>     a ModuleSystem subtype) that can both validate the contents of a
>     ModuleInfo as well as provide resolution based on it. While we
>     could potentially split validation across multiple such objects,
>     the compiler can't be responsible for combining multiple
>     resolution results into a single one. So it seems reasonable to
>     simply require any system that combines runtimes, layered or not,
>     to provide a single, combined implementation. In your example,
>     that implementation would have to combine logic for both OSGi and
>     Guice.
>
>
> Of course, using annotation-like module directive types addresses all 
> of these problems and enables some level of validation by the compiler 
> even when the module system can't perform higher-level validations 
> (simple misspellings won't just be ignored, for example). It also 
> feels a lot more like Java. ;-)
It only addresses the validation phase, not resolution. And validation 
is limited, unless we go to extremes in this annotation-like DSL  (e.g. 
supporting regex's for string patterns like version ranges, or some kind 
of validation methods that can be built into the class). But, perhaps 
more importantly, what about validation that spans directives (e.g. 
{requires foo @ 1.0; requires foo @2.0;})? Where does such logic go? The 
module system is the obvious answer, and it can also provide resolution, 
which the compiler requires at least as much as it does validation.

I'm not sure when it is the case that "the module system can't perform 
higher-level validations". The module system will be available to the 
compiler, or compilation will fail; we are simply considering (this part 
of) the module system api to be a compiler extension. And the same api 
will be available to any other tool or runtime.

// Bryan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/jsr294-modularity-observer/attachments/20090629/342f1fa2/attachment.html>
-------------- next part --------------
_______________________________________________
jsr294-modularity-eg mailing list
jsr294-modularity-eg at cs.oswego.edu
http://cs.oswego.edu/mailman/listinfo/jsr294-modularity-eg