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.
- Stanley
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.
// Bryan
