Updates on Interoperability

[Richard S. Hall]

Sam Pullara wrote:
> Did we decide which way it will be compatible?  I'm a little concerned 
> that implementing something that can use OSGi modules is a far bigger 
> task that implementing something that OSGi can use.  If we are going 
> for total compatibility it seems like we should just use OSGi.  
> Personally I wanted something in Java that was simpler and cleaner 
> that OSGi-users could leverage if they wanted.  But I'm coming at this 
> from the we-need-something-like-maven/gem/ivy camp.
>
> The vast majority of people that are going to use this system will 
> have never heard of OSGI nor care about any of their more subtle 
> features and just want an easy way to leverage the vast amount of 
> libraries available (virtually all of them are not OSGi modules today 
> but are jar files in maven repositories).  We shouldn't be specing out 
> some sort of uber container but rather a simple way to tie code to its 
> dependencies.

If this is all that people wanted, then we could just define 
repositories and associated metadata and forget about all runtime 
modularity support, but I strongly disagree that this is all people want 
or else there wouldn't be such an upsurge in OSGi interest and adoption.

> I strongly suggest KISS applies to our effort.  I write this knowing 
> that the committee seems to be heavily in favor of this alternate view 
> that we implement the kitchen sink.

I think our interest is similar, but perhaps our conclusions are 
different. Initially, I think my comments were construed as an argument 
against split packages in general, but I am really arguing the same as 
you (I think) that we don't really need split packages to be a concept 
in our "interoperability API", if that is how we are to view the 277 
API. Of course, I am also willing to have the former argument too, but I 
will leave that for another time. :-)

 From my point of view, I do not think it is wholly reasonable to assume 
that we want to try to accomplish interoperability across module 
systems, where that includes arbitrarily sharing split packages across 
module systems.

Let me try to accurately conjure the peculiarities of split packages in 
the OSGi module layer...

We support split packages in two ways, via required bundles (i.e., 
module dependencies) and via bundle fragments. In general, we recommend 
that if you split your packages that you attach mandatory attributes on 
them so that importers do not get them by mistake. By requiring a 
bundle, you can ignore mandatory attributes and get everything a bundle 
has to offer and combine it with other required bundles that might be 
exporting other parts of the split packages. Given this, there is a 
semi-reasonable chance* that we can tell you which bundles are 
contributing to the "complete" packages, but we have no way of knowing 
if/when combined split packages are complete. Further, we have to assume 
that split package parts offered by different bundles do not overlap, 
because if we allowed them to overlap then we would have shadowing and 
ordering issues. Again we have no easy way to verify that they do not 
overlap, so we just assume they don't.

Fragments on the other hand are a little trickier, since split packages 
from them are loaded from the same class loader to provide package 
private access (which is not afforded for split packages in the require 
bundle approach). The "host" bundle doesn't really know about fragments 
and it is possible for fragments to shadow or extend packages in the 
"host" bundle. Since fragments provide their split packages in an 
implicit way (i.e., they largely just become part of the host bundle's 
class path), there is no easy way to determine if a fragment is 
contributing to a given package or not. (* This feature of fragments 
also makes it so it is not really possible to know who is contributing 
classes to a split package in the require bundle case.)

I think that is fairly complete description of the situation, sorry if 
it is somewhat terse. In summary, I wouldn't assume that we can get 
reasonable interoperability at this level. If you need these types of 
features, then you should stick to a single modularity 
framework...preferably OSGi. ;-)

But my overall point is, I believe that if we can support 
interoperability at module- and package-level dependencies across module 
systems, then I think we would hit most use cases.

-> richard

>
> Sam
>
> On Apr 25, 2008, at 1:57 PM, Richard S. Hall wrote:
>
>> Bryan Atsatt wrote:
>>> Richard S. Hall wrote:
>>>> Gordon Hirsch wrote:
>>>>>> 1. Map its dependency declarations into a standard runtime 
>>>>>> representation.
>>>>>> 2. Support a standard search model over its stored modules, using 
>>>>>> the runtime dependency expressions.
>>>>>> 3. Map its stored module data into a standard runtime 
>>>>>> representation that can be returned by the search.
>>>>>
>>>>> One challenge lies in defining the "standard runtime 
>>>>> representations" and "standard search model" in a universal enough 
>>>>> way to encompass OSGi and other module systems. This implies 
>>>>> embracing concepts (in these standard representations and search 
>>>>> model) that were not universally liked by the EG early on. (Split 
>>>>> packages and package-level import/export come to mind.)
>>>>
>>>> Package-level import/export seem like a must, but I still don't see 
>>>> split packages as a necessity.
>>> Strongly agreed on import-by-package, and that ModuleDefinition 
>>> requires a method to enumerate exported packages (and probably an 
>>> exportsPackage(String packageName) method to enable an efficient 
>>> Query).
>>> On the split package front, however, it seems a little fuzzy to me. 
>>> If an OSGi implementation of 277 is also going to remain OSGi Rx 
>>> compliant, it will still need to support split packages, right? If 
>>> so, don't we need to surface this fact at the 277 level? Perhaps 
>>> that is as simple as acknowledging that Module.getImportedModules() 
>>> may return more than one instance that exports a given package.
>>
>> That all depends on if the 277 API is a subset of OSGi functionality 
>> or equal to it, I suppose.
>>
>> -> richard
>>>
>>> // Bryan