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

[Adrian Brock]

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