[snip]
Richard S.Hall wrote:
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.)
In general, I can say your two steps above are correct...Felix actually
has what amounts to a two-pass resolve that does (1) from above in the
first step and (2) from above in the second step. However, it turns out
that (2) is actually quite difficult and difficult to do in an
efficient way.
Perhaps it is more difficult for the OSGi framework due to some of the
sophistication of its model, e.g., package substitutability, fragments,
split packages, package-level uses constraints, etc.
All I know is that we are still finding cases that need to be clarified
in the OSGi framework for this process...
I won't say that I am disagreeing with you...if we can strip away some
of the complexity of the OSGi model, then I am sure you could implement
a reasonably straightforward resolver.
Right, that is what I'm trying to get at here. I believe *very* strongly
that import-by-name is a bad idea. Period. It is just plain wrong to do
the equivalent of "import foo.jar". We can do this already, with
manifest Class-Path. Simply layering version support on it does *not*
eliminate jar-hell!
It is far too brittle, raising all kinds of maintenance issues. Under
import-by-name, refactoring *requires* introducing a "facade" module to
avoid breaking importers. And this facade module now becomes *another*
product artifact to be managed: documented, maintained, distributed,
deprecated, and ultimately perhaps removed.
I truly believe that the Java world will be far better served by having
277 support ONLY import-by-package!
But there has been this background fear that import-by-package is
somehow terribly complex. I can certainly believe that the union of all
the OSGi features *does* result in a lot of complexity.
I just think that is almost entirely orthogonal to *this* domain, since
we are not trying to expose all those other features.
That won't necessarily help us in achieving interoperability, though.
Absolutely; regardless of the outcome of the import-by-package issue, we
still need to deal with exactly how the loaders can share classes and
resources...
// Bryan
