[jsr294-modularity-eg] Module directive types

[Bob Lee]

Evan Cowden wrote:
>
> First off, I like the grammar. Very spiffy.
>
Thanks!

>  That said, regarding:
>
>> 6. An astute observer might ask how we can reference type literals for
>> types
>> that come from modules. The answer is that we defer resolution and
>> validation of these types until after the modules have all
>> been resolved. Obviously, a directive that imports a module can't directly
>> reference types from that module. We can generate an error
>> when we encounter these cases.
>>
>  Should there be module requires directives for the modules containing the
> @module types? In the first example, there are imports (old-style, at the
> top of the file) for classes in the com.sun.jigsaw, org.osgi.jsr294 and *
> guice* packages, but no reference to them in any kind of requires
> statements (@module literals like com.sun.jigsaw.requires). If they are
> referenced from requires statements, the chicken-and-egg problem pops back
> up.
>
> The @module types that result in module resolution might come from a
compiler classpath or from the module system itself:

  public interface ModuleSystem {
    ClassLoader getDirectiveLoader();
    ...
  }

ClassLoader might not be the right abstraction here, but I'm sure we can
come up with something comparable and appropriate for use inside the
compiler.

Should @module types that don't result in module resolution be able to come
from other modules? That's a good question. Probably not, but we should
investigate the idea of evaluating directives for which the directive types
are available, loading the modules that result, trying to evaluate more
directives, repeat until no more directives can be evaluated.

> Second, regarding interoperability, does this mean that there will be
> different syntaxes for core functions for different module systems? Will I
> need to take special care to specify essentially different module files (or
> one large one with the contents of many) for my libraries to work in
> multiple systems? Without at least a minimal set of shared metadata, this
> seems to defeat the point of interoperability. Community projects will have
> to either target a specific module system, make a conscious choice to
> dedicate the resources to supporting several, or - the more likely one in my
> experience - decide to target the least common denominator: none.
>
> This if a fundamental problem with supporting arbitrary module systems.
Adding static types doesn't change anything. 3rd party libraries would
probably strive to support all module systems. Someone could write an
adapter layer to help (like commons logging :-)). Module systems could
choose to standardize and support common APIs (for example, all OSGi
implementations would support one API at least). Applications would probably
only need to support one module system.

> This would be pretty annoying alone, but it is not my biggest concern. This
> specification deals not just with runtime, but with compile time. If there
> is not core, shared metadata for each module system, then how does the
> compiler know which types are visible? BJ suggested last week that there
> might need to be some form of "compiler plugin" for each module system that
> interprets the different grammars.
>
> Which leads me to ask: does this mean I actually have to compile my code
> multiple times for different module systems?
>
> Even if they produce the same bytecode, I would still need to perform
> multiple compilations to confirm that my metadata is correct.
>
I'm afraid the answer is yes. Luckily only 3rd party libraries would have to
do this, and they could do it as part of a continuous build (many projects
already continuously build for multiple target platforms, especially
non-Java projects).

Bob
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/jsr294-modularity-eg/attachments/20090507/12fe41e6/attachment.html>