Minor incompatible changes

[Jesse Glick]

On 01/02/2012 05:02 AM, Jaroslav Tulach wrote:
> should there be a module "sheet" which is compiled against
> java.beans @ 1.8 and java.awt @ 1.8.2 and another module "customizer" compiled
> against java.beans @ 1.8.3 (and thus implicitly against java.awt @ 2.0.3),
> then it is impossible to turn those modules on at once (if only one version of
> java.awt may be on). I don't think this is a problem

This does not seem like a problem to me either - the sheet module simply needs an update to work with newer versions of java.awt.

But there seems to be a disconnect between the problem you are analyzing in your proofs and the actual problem here. Jigsaw does not in fact support loading multiple 
versions of a given module in an app, even if no linker inconsistency would arise as a consequence. That is why my demo program seems to be forcing the Jigsaw resolver to 
solve 3-SAT even though there is no reexport involved and so the repository is trivially "complete" in your terminology.

In other words, valid org.openjdk.jigsaw.Configuration's are much more restricted than the "configurations" in your "Library Versioning Terminology". If f7 at 0 used v3 at 1 
internally, i.e. as a utility and not making any mention of v3's types in its own signature, then it is nonetheless a problem for f7 at 1 or f7 at 2 to switch to v3 at 0, because 
the two versions of v3 cannot both be used at once. Of course the author of v3 could foresee this problem and provide different module names for incompatible releases 
(e.g. v3_0 at 0, v3_1 at 0, ...), but this puts the burden on the developer to work around a limitation of the module system, and it is ill suited to minor incompatible changes 
(i.e. those which would only affect a tiny minority of clients).

The fix might be for the module system to permit parallel loading of older and newer versions of a single module. This would bring reality into line with your definition 
of a "configuration"; and making it "complete" should be easy for plain old Java code - there is no inherent problem with "requires public", i.e. implicit reexport, so 
long as the compiler inlines the transitive dependency when producing module-info.class. The problem would be a module which really cannot be multiply loaded - either 
because it is used indirectly (e.g. via ServiceLoader), or because it has externally visible state (e.g. AWT, or an HTTP server). You could introduce a "singleton" 
qualifier for such modules, forcing at most one version to be loaded in a given configuration, but this reintroduces the NP-completeness to the resolver.