[Mod-Sys Reqs] Comment on "Substitution"
jesse.glick at oracle.com
Mon Jul 18 06:46:37 PDT 2011
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
> 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).
More information about the jigsaw-dev