Relationship to JSR 291 [was: Re: Bryan's comments]

[Stanley M. Ho]

Hi Bryan,

I don't think I will have time to response to all your comments this
week, so my response would focus on the import-by-package discussion.

First, the only import dependency we have consensus in this EG so far is
import-by-module-name (or import-by-superpackage-name), and this was
also what's in the EDR. That said, it is by no mean that we can't
consider other import dependency granularities (e.g.
import-by-package-name, or import-by-contract) in addition to
import-by-module-name. I would like to focus this discussion more on
whether it makes sense for JSR 277 to support additional import
dependency granularity, mainly import-by-package-name, and if so, in
what context.

There are three cases we should consider:

1. 277 module imports another 277 module by package name

I think our consensus so far is that this is nice-to-have or
non-critical, given we already have support for import-by-module-name.
To keep this discussion in focus, let's not dive into
import-by-package-name v.s. import-by-module-name, and let's assume
there is no support for #1 for now.

2. OSGi module imports 277 module by package name

As I discussed this with Richard in previous emails, majority of the
works for this fall under the OSGi framework if it wants to enable this
kind of wiring, but we could probably make the implementor's life easier
by provide the appropriate 277 reflective API if necessary.

3. 277 module imports OSGi module by package name

If I understand you correctly, I think what you really want is the
support for this case, so the existing OSGi bundles can be leveraged by
277 modules in a nature way.

Let me say it up front that I don't oppose the idea of #3 in the context
of interoperability. If #3 is what you really want, I think where we
diverge is simply how to make it possible.

Do you agree so far?

Bryan Atsatt wrote:
> ...
> I want 277 to explicitly expose the concept of import-by-package through
> appropriate APIs.
>
> It would be very nice if the 277ModuleSystem implementation itself
> directly supports import-by-package (case #3). But this is less critical
> to me than case #4...
>
> I want a 277ModuleDefinition to be able to import-by-package an
> OSGiModuleDefinition (i.e. a bundle exposed via the 277 APIs). I believe
> this case will be a particularly important one. By the time SE 7 ships,
...

As I described several emails back:

 > This doesn't mean supporting the notion of import by package is
 > impossible. What OSGi will expose from its repository is simply module
 > definitions, and module definition is basically an abstraction.
 > Therefore, it should be possible to treat an OSGi bundle as a module
 > definition, as well as to treat each exported package in an OSGi
 > bundle a module definition as well. The dependency supported in JSR
 > 277 is import-by-module. In the JSR 277 module system, this is mapped
 > to import-by-superpackage. In the OSGi module system, this can be
 > mapped to import-by-OSGi-bundle or import-by-package. If other module
 > systems want to support different import granularity or if OSGi
 > evolves to add new import granularity in the future, this model should
 > still work.

Rather than surfacing the import-by-package at the API level, I think we
can solve #3 by generalizing the import dependency concept as
import-by-name, and this name can be mapped to superpackage-name in JSR
277 and OSGi-bundle-name or OSGi-exported-package-name in OSGi (i.e.
exposing OSGi bundles and exported packages through implementing
OSGiBundleModuleDefinition and OSGiPackageModuleDefinition). I think
this is also what you intended to say at one point (correct me if I
misunderstand you) by suggesting to change
ImportDependency.getModuleName() into something like
ImportDependency.getName().

We expect the module-aware compiler would somehow recognize the import
dependency defined in 277. In other words, if the OSGi framework exposes
the module definitions appropriately, you'll get the compiler support.
Since the import dependency is generic, the compiler and other tools ed
to do extra work to support other forms of import dependency.

In case if the 277 module would like to import these OSGi exported
packages using an OSGi-like resolution algorithm, it should be possible
for it to use a custom import policy (or import override policy or maybe
some new override mechanisms) to get the behavior it wants.

Do you think this is a workable approach to address #3?

- Stanley