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

[Bryan Atsatt]

[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