Stanley M. Ho wrote:
Hi Richard,
Richard S.Hall wrote:
...
Perhaps so.
I am operating off my [possibly dated] recollection that 277 modules
explicitly list the classes that they export, which meant that they may
expose arbitrary public classes from a package. If this is no longer
the case, then this is fine.
The point remains, all legacy OSGi dependencies on a package assume
that all public classes are exported from that package. An OSGi
dependency on a given package cannot be resolved to a 277 module whose
"exported public" classes are not the same as all "public" classes in
the specific package.
I was under the impression that the class filtering is also in effect to
determine which public classes are exported from that package in OSGi
and that the OSGi dependency on a package already has a similar
"exported public" concept.
This is definitely true, but this was only introduced in R4 and is still
intended to be the exception, not the norm...from my understanding, 277
defined the norm in the opposite direction.
Ultimately, if we are making the same assumption, which is that people
will generally be exporting all public classes from a package and only
occasionally filtering some classes that should not be public, and we
are promoting this as the best practice, then we are at least in the
same ball park.
Anyway, these are all related to how the OSGi framework might import 277
modules by package name. I think it would be good to know if this is
actually a sensible thing that the OSGi framework wants to support
before we dive too deep on this. Glyn/Richard, is this something that
you foresee the OSGi framework will support?
Well, effectively all OSGi dependency resolution comes down to packages
at some point, so if we are going to use 277 modules at all in the OSGi
framework, then we have to have some way to determine their set of
exported packages, which is necessary for determining consistency.
-> richard
