Updates on Interoperability
Stanley M. Ho
Stanley.Ho at sun.com
Fri Apr 25 15:53:38 PDT 2008
The current APis do not prohibit module definition to have split
packages. It is only when a Java module is instantiated from the module
definition, the implementation of the default module system would
perform shallow validation and consider split packages as an error.
Other module system implementations can continue to have their own
validation policies to resolve their modules.
I hope this will become more clear when the details are available next week.
Bryan Atsatt wrote:
> Richard S. Hall wrote:
>> Gordon Hirsch wrote:
>>>> 1. Map its dependency declarations into a standard runtime
>>>> 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
More information about the jsr277-eg-observer