Conflicting module versions

[Tim Boudreau]

>
> The practicality of software is that specific versions are what you test
> with.  Subsequent versions may not be compatible and just because you need
> to use another software package that needs a newer version should not
> dictate that rework occur.  Yes, it might be a good thing, but...
>

I think it's interesting that, for example NodeJS's library delivery model
is that you can and will have as many different versions of a library as
you want (since NodeJS's namespacing is the filesystem itself, you can have
A/node_modules/libbar depending on B which has a different
node_modules/libbar).  Since NodeJS is Javascript, if an object from A's
libbar meets an object from B's libbar, they can interoperate if
duck-typing allows them to (it also means you find out very late in the
game if they don't).

I bring that up to point out that the whole model of "use the libraries on
the system" - i.e. linking against unknown versions of things at runtime -
is less important today than it once was.  In a world where deploying
usually means spinning up a new OS instance which contains known and
known-to-work versions of things, the problems of long-lived machines where
libraries will be upgraded in-place many times are less worth solving than
they once were.


> What we need the most is a way to cleanly separate and isolate software.
> Netbeans has a class loader hierarchy that tries its best to keep things
> separated.  I like that.  The Java, conventional hierarchical class loader
> structure helps prohibit lateral views, which for me, create the largest
> exposure to hassle.
>
> What would be good, is to figure out a way to keep objects from one branch
> of the tree from ending up in another branch of the tree when that branch
> is not compatible.
>

FWIW, Maven has this via the maven-enforcer-plugin - turn on
DependencyConvergence and it will fail the build when multiple versions of
something are on the classpath.  That means you have to do something when
it happens, but it guarantees it won't happen without you knowing it.


> I think about it as a set theory problem.  The package names and classes
> and versions represent a "set".   Discarding the version is the problem in
> considering where overlap can occur.    There can never be a proper
> intersection between two versions.
>
> If we had tools that could analyze these sets to determine that there was
> in improper intersection in visibility, that would help make it clear to
> developers that their code was interacting in a way that incompatibility
> and class cast exceptions would occur.
>
> Then, having a way to unmarshal an old version and remarshal to the new
> version as a "proxy" or "delegate" through lambdas would be awesome.
>

What you're asking for is duck-typing in Java :-)  Or, really, something
more like a classloader that can see both versions of a library, and if the
serialVersionUID that would be generated for both is identical, to treat
them as interchangeable.  Which is theoretically implementable, but would
either require a lot of runtime type information that doesn't exist now, or
would impose a substantial performance penalty at runtime (loading any
class would involve some search and compare operations).

Anyway, I fear we're wandering off topic here.  Do you believe that this
JSR should *implement* these things, or just facilitate the possible
implementation of them?

-Tim