Updates on Interoperability

[Bryan Atsatt]

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.

// Bryan