Conflicting module versions

[Gregg Wonderly]

On 2/7/2015 3:17 AM, Tim Boudreau wrote:
>
>     Demanding that only one version of B can exist will pretty much keep me
>     and a lot of other people from caring about or contributing to what might
>     happen with this JSR.
>
>
> I think the trick is to provide a non-hacky way that someone can plug 
> something that can create a hierarchy of classloaders using whatever hierachy 
> it chooses (and yes, that has some implications for that thing's load-order 
> and privilege), without forcing that down the throats of all applications, 
> since such things add overhead and complexity that not everything needs.
>
> I think there's a spectrum from "prove it works" to "pray it works" with a lot 
> of stops in-between that different kinds of applications have tolerance for (I 
> once was hired to untangle a huge application used in some very scary places, 
> which was routinely built and deployed with an additional ancient version of 
> itself on the classpath because the sources to some classes had been lost and 
> nobody there understood what they did), and different trade-offs along the way.
>
> Are you looking for the JSR to solve the problem, or just to make it 
> straightforward to layer a solution on top of it?
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...

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.

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.

I've put these version proxies into play in many cases as a way to solve 
interactions across versions when needed.  It's not pretty, but sometimes there 
are really no other choices.   In some cases, there are serialization 
implementations in widely used classes which already do this, and thus you can 
create marshalled object instances to pass around to other places and just 
unmarshall them in the other versions class loader.

Gregg Wonderly