Minor incompatible changes was: Comments on the proof

[Jaroslav Tulach]

Hello Jesse.
First of all, I don't think incompatible changes should be treated as lightly 
as you indicate. But even if we follow your example, I don't think we are 
forced to do something unnatural...

>## 27. 12. 2011 18:30:52 ##<
> > I am glad avoiding NP-completeness is preferred. It increases my
> > enthusiasm to seek for a dependency system that would be powerful enough
> > and avoid it.
> 
> An apparent precondition of your proof about complete repositories which
> was not adequately emphasized is that a module must declare itself
> incompatible if anything it reexports is incompatibly changed. 

True and correct, but the case below is wrong example. The module should only 
be marked as incompatible, if it really re-export the incompatibly changed 
class.

> As I have
> written before, this is not a restriction to be taken lightly! Consider
> that java.beans.PropertyEditor.getCustomEditor() returns a
> java.awt.Component, i.e. module java.beans @ 1.8 requires public module
> java.awt @ [1.8,2), so anyone with a dep on java.beans [1.8,2) gets an
> implicit dep on java.awt @ [1.8,2) as well. Now suppose that later it is
> decided to finally just delete java.awt.List.delItems(int,int) which
> probably no one calls anyway, and to be on the safe side java.awt is
> bumped up to 2.0 accordingly. But now the next release of java.beans must
> reexport java.awt @ [2.0,3), meaning by the postulated rule it must also
> be marked 2.0. 

If you look at the definition of complete repository[1], you'll find out this 
is not necessary. You can release java.beans @ 1.8.3 which requires public 
module java.awt @ [2.0.3]. The repository will still remain complete and 
consistent.

Of course, it would be beneficial if the system verified that none of the 
incompatibly changed classes are re-exported - e.g. that java.beans does not 
export something like "class BetterList extends java.awt.List". A tool like 
sigtest[2] integrated into jmod would be handy in such verification process.

> > And that means that a module with a property editor based
> on Swing, never using java.awt.List at all and otherwise happy with
> java.awt @ [1.8,3), is forced to drop support for java.beans 1.x. 
> Indeed a
> module using java.beans.Introspector for server configuration from
> properties files and never using PropertyEditor or loading any AWT classes
> whatsoever will also be forced to drop java.beans 1.x

A server-side module(s) without any dependency on java.awt can have dependency 
on java.beans @ 1.8 and link without any problems with java.beans @ 1.8.3. So 
this is not an issue.

On the other hand, 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[3] (as the situation 
seems like an error anyway) and the solution is simple: enough to produce new 
version of "sheet" recompiled with java.beans @ 1.8.3

> The situation would be more robust if reexports were dropped, modules were
> required to explicitly specify all their direct dependencies 

The proposal for complete repository[1] in fact drops re-export and modifies 
compiler to explicitly specify all dependencies. Minor (e.g. unrelated) 
incompatible changes seem to be supported under this scheme.
-jt

[1] 
http://wiki.apidesign.org/index.php?title=LibraryWithoutImplicitExportIsPolynomial&useskin=monobook
[2] http://sigtest.java.net/
[3] If it is, there is a solution at the cost of more complex dependency 
specification - still one needs to produce new version of "sheet" anyway.