Relationship to JSR 291 [was: Re: Bryan's comments]

[Richard S.Hall]

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