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

[Bryan Atsatt]

Stanley M. Ho wrote:
> 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.

Agreed.

>
> 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.

Yes, the API would be useful.

>
> 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?

Yes.

>
> 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().

I believe we are now thinking along the same lines.

I just sent an email on the topic of generalizing the import dependency
concept, with the subject "Import constraints". With the approach I
suggest there, the distinctions between module-name and package-name are
mostly transparent to the runtime (declarative support for package-name
is not addressed).

That isn't to say that there aren't resolution issues to be worked out
for package-name, but its a start.

>
> 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.

Yep. As I've said from the very beginning, I think the compiler is going
to have to rely on the 277 runtime to resolve *external* (i.e.
non-source) dependencies. So as long as the runtime can deal with
package-name, the compiler will too.

(Dependencies resolvable via included source will, I assume, just
*directly* resolve, without applying any constraint logic. That is, if a
class refers to a class in another superpackage, and that class &
superpackage are available in the same compilation, the compiler will
simply select them without applying *any* constraints. This may be too
simple of a model, but maybe it is sufficient.)

>
> 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?

I don't think custom code should be required; we need to make it easier
than that or it doesn't qualify as "first-class" citizenship, at least
not to me :^).


I guess I am still missing something fundamental--I keep thinking that
import-by-package is actually not so hard. There are three main components:

1. Declaration.
2. Runtime infrastructure.
3. Resolution algorithm.

I'm pretty sure that #2 is easy (and covered in my "Import constraints"
thread).

And we don't yet have *any* import declaration mechanism (yes, we're
assuming that this will be handled in 294, but it hasn't been brought up
yet). I don't see this as a difficult issue either way. It would be
natural to have both import-by-name and import-by-package in
superpackages, if we have import at all. If we need to use annotations
instead, it is easy to have both types.

So I can only assume that the *real* concern here is #3. And I can't
tell if this is a valid concern or not. I hope Glyn and Richard will
point out what I'm missing here...

What is the difference between selecting a ModuleDefinition based on its
name, or selecting it based on its contents? Either way, "shallow"
validation must still occur.

// Bryan

>
> - Stanley
>