On May 31, 2007, at 8:06 PM, Stanley M. Ho wrote:
Hi Richard,
Richard S.Hall wrote:
I don't think I fully understand your concerns around exporting an
entire package. As you mentioned, what's get exported in 277 module
is
in terms of classes and the information is in the module metadata,
and
I
think we can probably determine the packages associated with these
exported classes and treat these packages as "exported packages" from
the OSGi perspective. There is no split package allowed in 277
module,
so I think each of these exported packages would be an entire
package.
The point is that an OSGi exported package FOO specifically means that
all public classes in the FOO package are accessible to importers.
Such
an export is not the same as a 277 module that just happens to export
a
class in its export signature from the FOO package. Without cracking
open the module, there is no way to tell if its export signature
contains all public classes from the FOO package (i.e., the entire
package).
-> richard
I think there is a misunderstanding here. Both JSR 277 and OSGi export
all "accessible" classes in a package. JSR 294 changes what accessible
means from "public" to "exported public", and this affects 277 and OSGi
in the same way. I don't think there is a conflict here.
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.
-> richard
