[Mod-Sys Reqs] Comment on "Substitution"

[Peter Kriens]

On 18 jul 2011, at 15:46, Jesse Glick wrote:
> On 07/18/2011 03:07 AM, Peter Kriens wrote:
>> Importing/exporting versioned packages gives you exactly what you need
> This would seem to be functionally similar to module substitution, with the exception that the package rather than the module is the unit of versioning. The same concerns about mixing signatures with implementation apply.
I do agree this is an issue with almost any JCP API as they mix factories, implementations, and specifications.

For this reason, inside the OSGi we strictly separate those issues and ensure that our packages are well versioned and have only API (which interfaces implemented by the provider of the API, the consumer of the API, and often implementations of permissions.

> A concrete example is the hassle encountered with Java EE APIs in Maven: some classfiles had method bytecode stripped out so that they could not be misinterpreted as an "implementation" of the specification and thus subject to the TCK. This hack was only needed because there was no such thing as an official API JAR to begin with - you could only copy JARs that were mostly API from an app server installation.
In OSGi, each package lives on its own as the contract. As in JEE often packages end up in the VM and are specified independently of the VM I think it is not a good idea to believe in a JEE "profile". I think the mess of JME shows what happens if you tried to aggregate highly different things into a single release model.

> Most libraries that would be candidates for modularization would not run into this kind of issue because you either use the module or you do not; if you mostly like it but have some improvements to make, you make them upstream. The substitution feature seems to be geared toward APIs which are developed as an abstract specification by some standards body (typically alongside a reference implementation) and intended to be reimplemented by several vendors.
Yes, like most of JCP and all of OSGi.

> There is the unmentioned use case of apps which just want to bundle a patched copy of some library. These might also benefit from substitution, though it is common in such cases to also want to make minor API additions in the patch, in which case an explicit dependency from the other modules in the app to the fork would be necessary anyway.
Very true and very much into our visor.

>> you're basically rediscovering OSGi's service model
> Indeed - there are various service models out there. I am simply trying to respond in the context of "Java Module-System Requirements", which (a) offers a very simple service model, (b) then offers another feature, substitution, which a service model could subsume (in the case of new APIs).
But I think we should not develop new constructs if existing concepts can be used instead and I think packages are an excellent candidate for what you propose if they are used properly by the specification authorities.

Kind regards,

	Peter kriens