[Mod-Sys Reqs] Comment on "Substitution"

[Jesse Glick]

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.

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.

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.

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.

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