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

[Richard S.Hall]

On Jun 7, 2007, at 7:53 PM, Bryan Atsatt wrote:

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

Well, you are preaching to the choir with me. I argued long and hard to
keep require-bundle out of OSGi R4 for the same reasons you list above
(I lost that battle). I also encourage everyone who wants to use
require-bundle to read the section in the OSGi spec that lists many of
its limitations and issues (which were extended in OSGi R4.1).

I would also be happy if 277 only supported import by package, but I
stopped arguing for it since it was kiboshed early in the EG
discussions.

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

So, I guess we are in agreement, even if the rest of the EG isn't. :-)

-> richard