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
