*Bryan Atsatt <[EMAIL PROTECTED]>* 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...
