The discussion is mainly about what exported / imported content is and should be. For OSGi, this is about packages and modules (even though the later are seen as a burden that is there for political reasons), whereas Jigsaw modules will export types and import modules. I have done quite a bit of Eclipse programming in the past and this made me think a lot about exporting / importing content. I think the distinction between two layers of abstraction (the module, and the service layer – in case of Eclipse the extension registry) which even have different meta data formats is artificial and often leads to errors. Ok, the Eclipse UI tries to hide this, and one could argue that there are now attempts to build more consistent service layers and the situation in Eclipse is caused by history, but I think there is a much simpler solution to the problem.
Lets just remember how OSGi works at the moment. We have the following two types of module collaboration:
- module 1 requires package version range - module 2 provides versioned package
- module 1 requires module version range - module 2 provides a versioned bundle (=itself)
When using a service layer such as the Eclipse extension registry or declarative services, other collaboration types are added to the mix, in particular the following:
3. module 1 requires interface - module 2 provides class
The contracts that define the correctness of the application are pretty simple: “version must be in version range” for types 1. and 2., and “class must implement interface” for type 3. By the way, this is not only about Java artefacts, there are many use cases for other types of collaborations between modules, such as:
4. module requires xml instantiating a certain DTD – module provides XML
This type of contract is used in the Eclipse help system. My point is the following: perhaps we can and should be able to export / import all of the following: modules, packages, types and other artefacts. The key is a simple abstraction: modules declare what they need using typed resources (types are package version ranges, Java interfaces, DTDs, etc), and export what they can provide as typed resources (types are package versions, Java classes, XML resources, etc). Module system containers such as OSGi can then use the relationships between those resources (version matches version range, class implements interface, document validates against DTD, etc) to wire modules (=create classloaders) and verify assemblies (e.g. to check compatibility between classes and interfaces).
See also http://code.google.com/p/treaty/ - a prototypes we built a few years ago that implements some of these ideas.