Exported Classes and OSGi Re: Supporting OSGi Bundles in the Java Module System

[Stanley M. Ho]

Hi Adrian,

Adrian Brock wrote:
> On Mon, 2008-04-28 at 20:16 -0700, Stanley M. Ho wrote:
>> 3.2 ModuleDefinition class
>> Two new methods are added in the ModuleDefinition class to return the
>> exported packages and member packages respectively. The export and
>> member definitions contained in the OSGi metadata are in package
>> granularity. In addition, a new PackageDefinition class is added to
>> allow an OSGi bundle to expose the metadata for an exported package.
>> This is required to meet the requirements (1) and (2). 
>>   ModuleDefinition class:
>>       public abstract Set<PackageDefinition> getExportedPackageDefinitions();
>>       public abstract Set<PackageDefinition> getMemberPackageDefinitions();
>>       
>>   PackageDefinition class:
>>       public abstract class PackageDefinition {
>>           public String getName();
>>           public Version getVersion();
>>           public Set<String> getAttributeNames();
>>           public String getAttribute(String name); 
>>       }
> 
> ModuleDefinition still refers to exported and member classes.
> Although this is probably more of an issue for 294/291 interoperation,
> I don't think 291 has such notions?

With modules in the language, only public types are accessible outside 
their development modules. A deployment module system could leverage 
this by considering public types (or a subset thereof) as 'exported', 
and the granularity of exports can therefore be types or packages. The 
JAM module system integrates tightly with development modules and it 
will expose type-level exports, but other module systems can continue to 
expose package-level exports. Thus, ModuleDefinition should support both 
granularity levels. If a module system does not support type-level 
exports (e.g. 291), the implementation of 
ModuleDefinition.getExportedClasses()/getMemberClasses() could simply 
throw UnsupportedOperationException.

- Stanley