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

[Adrian Brock-4]

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?
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx

[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

[Adrian Brock-4]

On Tue, 2008-06-10 at 17:10 -0700, Stanley M. Ho wrote:

> > 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.
>

So a 291 module that hasn't been updated to reflect changes from 294
would just expose package exports and the importing 277 module
would know how to deal with that?

The 291 module classes would be like legacy classes that
don't belong to a module in the 294 sense.
i.e. Class.getModuleInfo() would return null

> - Stanley
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx

[Stanley M. Ho]

Adrian Brock wrote:
> So a 291 module that hasn't been updated to reflect changes from 294
> would just expose package exports and the importing 277 module
> would know how to deal with that?

A 291 module which exports packages is fundamentally exporting public
types, which will continue to work across module boundaries. If a JAM
module imports a 291 module, it'll know how to deal with this if
getExportedClasses() is not supported in the imported ModuleDefinition.

> The 291 module classes would be like legacy classes that
> don't belong to a module in the 294 sense.
> i.e. Class.getModuleInfo() would return null

Types which are not in a named module are in the unnamed module; the
changes in the Java Language Specification (JLS) will say this. null is
probably as good a value as any for representing this.

- Stanley