On May 30, 2007, at 5:55 PM, Stanley M. Ho wrote:
Glyn Normington wrote:
*Bryan Atsatt <[EMAIL PROTECTED]>* wrote on 30/05/2007
07:57:59:
...
> So the open issue is the richness of the import "language":
must we
> support only lowest-common-denominator, or can we do better
without
> over-complicating the design?
>
> I for one would like to be able to have a single module express
> dependencies on modules from both the same and different
ModuleSystems,
> *using the standard semantics of each*. This may be reaching
too far,
> but we should at least explore it seriously while we figure out
what
> interop means here...
At this point, I feel that is likely to be reaching too far, but I'm
happy to play along and see what we can learn along the way.
I agreed with Glyn that this might be reaching too far. Before we dive
too much into how to implement interoperability, I think one of the
outstanding questions we should answer first is what degree of import
interoperability we want to offer. There are four possibilities:
1. JSR 277 module imports OSGi module by module name
2. OSGi module imports JSR 277 module by module name
3. OSGi module imports JSR 277 module by package name
4. JSR 277 module imports OSGi module by package name
Let's ignore the 294 issues and the module initialization issues
for now
to simplify this discussion.
I think we all agreed #1 and #2 are important to support and the
reflective APIs already enable these (of course, there are minor
issues
we still have to address as we evolve the APIs.)
That said, it is unclear to me how important it is to support #3
and #4,
so I think the first question for this EG is whether we want to
support
#3 and #4 at all. However, let's pretend #3 and #4 are important for
this specific discussion.
I think #3 is already possible since the OSGi framework could look up
the appropriate module which exported the package in the repository,
using the reflective APIs. Afterwards, the OSGi framework can then do
the necessary wiring. Yes, the reflective APIs can be further
refined to
make it easier for the OSGi framework to query modules by exported
package name from the repository, but this is a minor issue that we
can
address easily.
I am not so sure supporting #3 is as straight forward as you suggest
here. Specially, the OSGi modularity layer [for the most part]
assumes that packages are atomic units; there is no way to specify
that your export or import something smaller than a package. Since
277 modules declare exports in terms of classes, it is not clear how
we would know if a 277 module was exporting an entire package. This
would, at a minimum, require that we assume we can inspect the
contents of the module and see that the contents of a contained
package matches the module's export signature for that package.
-> richard
#4 is a bit complicated, because there is no import-by-package
semantic
in the current module layer's APIs and I think we all agreed that we
don't want to support this semantic directly in the module system
defined by JSR 277. In this context, the question is really about what
it would take to make #4 possible if we want to support it, and so far
there are two different approaches we have discussed:
a. Treat import-by-package separately from import-by-module in the
reflective APIs and make the module layer fully aware of the
import-by-package concept.
b. Expose exported-package using the ModuleDefinition abstraction, and
provide necessary hooks (e.g. consistency checking) for the module
system to resolve this kind of dependency appropriately. The module
layer is not aware of the import-by-package concept at all. New import
dependency granularity could also be introduced in a similar manner in
the future without requiring significant changes in the module layer.
As Richard and I discussed in previous emails, it seems to make the
most
sense for JSR 277 to define the minimal set of features possible in
the
module layer to accomplish what needs to be accomplished to provide
core
modularity support in the Java platform. I think (b) follows this
principle nicely while (a) does not. If we decide to support #3 and
#4,
then how we want to address #4 would impact our overall design
significantly.
Is there anyone in the EG provide good reasons why #3 and #4 are
important to be supported? If so, is there anyone in the EG think
(b) is
not feasible at all and we should do (a) instead to support #4? Can
you
explain your rationale?
> RESOLUTION MODELS
>
> The current design requires that each ModuleSystem provide its own
> resolution logic, and that each definition will be resolved by its
> owning ModuleSystem. This model appears to provide flexibility for
> significant differences in implementation, but we really don't
know
> enough at this point. Perhaps only an actual second
implementation will
> tell us if this provides useful flexibility.
In the existing module systems we are aware, e.g. OSGi and
NetBeans, we
already know their resolution logics are different from each other.
Even
if they are migrated/re-based to JSR 277 in the future, I think we
should expect their resolution logic would remain the same to maintain
backward compatibility with their existing modules/bundles. In other
words, their resolution logic would still be different from each
other.
A phased approach would be particularly beneficial if the initial
phase
could be delivered as part of Java 7 and subsequent phases
implemented
strictly on top of Java 7. But getting the API right up front
might be
tricky unless we can spot some really good abstractions or
prototype the
later phases sufficiently well. Is that the kind of phasing you
had in
mind?
Once an API is put into the SE platform, it will stick around almost
forever. I think if we go with the phased approach on interoperability
support (I believe this is what Bryan suggested), it would be much
better to simply left out those features/APIs which do not have
implementations to back them up from JDK 7, rather than putting the
half-baked features/APIs into the release and regret later. ;) We can
always add new APIs in subsequence releases if we decide to offer
better
degree of interoperability in the future.
- Stanley
