No isolation was: Minor incompatible changes

[Jaroslav Tulach]

>## 3. 1. 2012 20:15:25 ##<
> 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.

Yes, there is a terminology disconnect. However the concept remains the same. 
There has been similar proofs (some of them referenced at [1]) and they don't 
deal with concept of re-export. 

My proof is unique as it does not need concept of "obsoletes/prevents" 
dependency which mimics negation in the 3SAT problem. I substituted that with 
requirement that every class name has to have a unique meaning in each class 
loader.

If Jigsaw decides to support no isolation (e.g. enable just one version of 
module in the application), then the problem remains the same (as your demo 
program demonstrates). Basically it means that every usage of a module is 
counted as re-export (as it prevents any other module in the system to use 
different incompatible version of that module). Sort of like saying that every 
class name in the system should represent unique class.

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

Right, that sounds like my expectation. However even if Jigsaw sticks with 
single version of a module per application, having transitive dependencies of 
each module enumerated by compiler will pay off.

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

Singleton module maps to module which every other module with dependency on it 
"re-exports" (in terminology of [1]). I don't think this brings NP-
completeness back. If all transitive dependencies are enumerated by 
compiler[2], it is polynomial problem to select a version of such module to 
use (or reject the configuration as inconsistent).

-jt

[1] http://wiki.apidesign.org/wiki/LibraryReExportIsNPComplete#External_Links
[2] 
http://wiki.apidesign.org/wiki/LibraryWithoutImplicitExportIsPolynomial#Consistency