(Complete) range dependencies back in the game?

[Stephen McConnell]

Jaroslav said:

    <quote>I am not real fan of separating SPI and API. </quote>

I recognise your position but question your judgement.

    <quote>almost nobody understands what SPI vs. API is</quote>

Which is basically saying that within your circle of influence - the 
distinction is not present? I get that. It doesn't mean that we have to sink 
to the lowest common denominator. I need better than that - I need the 
solutions that will take my best and brightest to the next step. Frankly I 
don't care too much about the 'almost nobody' spectrum. I do care intensely 
about that selective set - those people your refer to as "almost nobody" - 
the ones that get this stuff and do it day in and day out and expect the 
next generation of tooling to meet their professional aspirations.

Cheers, Steve.

-----Original Message----- 
From: Jaroslav Tulach
Sent: Monday, March 26, 2012 1:20 PM
To: jigsaw-dev at openjdk.java.net
Subject: Re: (Complete) range dependencies back in the game?

Hello guys,
I am not real fan of separating SPI and API. Either the designer knows what 
is
the goal or not. Either the class should belong to API or SPI. Such
distinction is possible even now in Java. Whether it needs some special
constructs in the future depends on our understanding how frequent such 
usage
case is. We may expect it is frequent because almost nobody understands what
SPI vs. API is. Rather than changing the language, rather than changing the
modularity, it would be better to restrict and define what makes sense.

>## 13. 1. 2012 08:34:23 ##<
> On 01/08/2012 11:44 AM, Jaroslav Tulach wrote:
> > http://wiki.apidesign.org/wiki/RangeDependenciesAnalysed
>
> "It does not make much sense to have higher upper bound of dependency on C
> higher than any existing upper bound on C among reused libraries (thus s
> <= q)" - I disagree that this does not make sense.

The basic problem is not about disagreeing, however about providing
flexibility while keeping the system powerful enough.

> Let us say that C has both an API and an SPI; the API is kept quite stable
> but the SPI is frequently rewritten (and the handful of implementations
> are expected to keep up). So pretend C is DOM, and API clients normally
> use ranges like [1.2,2) ("DOM 2 or any foreseeable compatible release")
> whereas SPI implementations normally use ranges like [1.2,1.3) ("DOM 2 but
> not 3").

Jesse, I know you are obsessed by different stability levels of API and 
SPIs.
True, you are not the only one. I am just saying we can do much better. 
Those
who assumed certain classes will never be implemented by NetBeans IDE were
wrong! We have implemented almost everything! If it was just an attempt to
intercept the calls - if there is an interface, people will implement it.

So just stop your "friendly implementor vision". It hurts everyone. Try to
behave like real "distributed fan" - allow people to evolve on their own, 
just
keep backward compatibility.
-jt


> Now pretend B is a library for XML persistence of Java objects, and during
> one serialization mode it creates flyweight org.w3c.dom.Document's.
> Versions 1.0 through 1.3, written back when DOM 2 ruled the land, declares
> [1.2,1.3); version 1.4 and later implement DOM 3 so declare [1.3,1.4) but
> are otherwise fully compatible for callers.
>
> Finally say A is an application which uses XML serialization for some
> preferences storage, and also uses DOM quite independently for dealing
> with REST clients. So it would like to declare B@[1.0,2) and C@[1.2,2): it
> uses only the basic initial serialization API, and can work with any known
> DOM release.
>
> The fact that B at 1.0 is incompatible with C at 1.3 does not trouble the author
> of A; the app would work fine with B at 1.5 and C at 1.3 as well. If the
> compiler silently converted the dep on C@[1.2,2) to C@[1.2,1.3), it would
> effectively mean that B at 1.4 could not be used even if it had numerous bug
> fixes, which is generally not what you want. It could instead just reject
> A's attempted expression of what its actual dependency ranges are, with
> some sort of error message TBD, and the author of A would (after some
> trial and error) eventually give up on supporting older libraries and
> request B@[1.4,2) and C[1.3,2).
>
> This switch would be rather artificial: the originally attempted 
> dependency
> declaration was logically sound, and a module system using a SAT solver
> would not have difficulty linking A with either newer or older libraries
> according to what is available. (An organization which decided it hated
> the DOM 3 license might forbid it from being installed, in which case you
> would like to be able to run A with B at 1.3 and C at 1.2.)
>
> Indeed if A does not use XML namespaces in its REST API, it could as well
> declare C@[1.1,2) even knowing that current versions of B require at least
> C at 1.2; a future version of B might stop needing to implement DOM and (if
> it did not use namespaces either) might declare C@[1.1,2), in which case
> B at 1.7 C at 1.1 would be a valid configuration too. Obviously this is a less
> likely scenario, but it shows that "[t]his definition seems to make sense
> from the point of lower bound" is not so obvious either.
>
>
> On this topic, I think the definition of complete repository is
> unnecessarily strict; there is no reason apparent to me why [r,s) must be
> a subrange of [p,q), though it does at least need to overlap (and probably
> a version of C in that intersection must actually be present in the repo).
> Where in the proof is the assumption of subranges used? You only check
> whether cr is empty, which it would be in the attempted conversion to
> 3-SAT. It seems that A could express any dependency on C it likes, and
> trying to compile A would either work or not work, according to whether
> its dep on C has at least some overlap with that of the earliest versions
> of its other dependencies.
>
>
> By the way, you do not really discuss selecting a configuration at install
> time in a complete repository. [1] does not seem to apply to arbitrary
> range dependencies. Probably you can start with a configuration using the
> lower bounds of all dependencies as determined during compilation, then
> iteratively try raising the version of each module individually so long as
> doing so continues to result in a valid configuration - i.e. pick a
> locally maximal configuration. This is polynomial.
>
>
> [1]
> http://wiki.apidesign.org/wiki/LibraryWithoutImplicitExportIsPolynomial#Me
> rge_of_Configurations