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

[Bryan Atsatt]

Glyn Normington wrote:
>
> *Bryan Atsatt <bryan.atsatt at ORACLE.COM>* wrote on 04/06/2007 20:21:29:
>
>  > 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...
>
> Sounds right to me. However, the JSR 291 support for import-package is
> more subtle, and I would say was generally harder to get right (over
> several versions and several years), than require-bundle which was added
> fairly simply (despite the semantic rough edges, pointed out in the
> spec.). Although JSR 277 has paid lip service to learning from OSGi, the
> design is radically different in several ways:
>
> * dependencies expressed in metadata and code rather than purely in
> metadata
> * split packages not allowed
> * shallow/deep validation to avoid class space inconsistency rather than
> metadata expressing package dependencies and a system provided resolver
> that aims to find a "best fit"
>
> so my feeling is that we've got a quite a lot of work to do to support
> something equivalent to import-by-package. Of course, it may turn out to
> be simpler than I expect...

And that's what I'm struggling to determine. I do understand that 277
has taken a different approach, and so there is some cognitive
dissonance here.

But, the list you cite above seems a bit hand-wavy to me (sorry :^),
perhaps just distinctions without a difference.

My question below still stands. In general, it seems to me that
resolution consists of:

1. Selection of candidate module/bundles based on import declarations.

2. Class space consistency validation (which may narrow the list if
multiple choices, or result in a failure).

I don't understand what possible difference it could make whether we use
a module name or a package name to select candidates in step 1. Or even
if some custom code makes that selection (though I'm not a fan of this
either.)

Can anyone explain what difference it might make?

The selection criteria are entirely up to the developer/deployer; our
job is to make the best choices *within* that scope at runtime, or fail
if required if they violate the rules.

// Bryan

>  > 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
>  > >
>
> Glyn
>
>
> ------------------------------------------------------------------------
>
> /
> /
>
> /Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU/
>
>
>
>
>
>