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

[Glyn Normington]

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

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





-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/jsr277-eg-observer/attachments/20070605/c58a9202/attachment.html