Conflicting module versions

[Gregg Wonderly]

> On Feb 9, 2015, at 9:18 AM, David M. Lloyd <david.lloyd at redhat.com> wrote:
> 
> Comments inline.
> 
> On 02/06/2015 11:17 PM, Gregg Wonderly wrote:
>> I'd personally prefer that a dependency graph with branches such as
>> 
>> A->C
>> A->B.v1
>> C->B.v2
>> 
>> be resolved with both version of B loaded and a ClassLoader hierarchy
>> that puts each version of B's parent class loader pointing at
>> the same classloader that A and C are loaded with.   A and C may not use
>> B in any common code paths and objects from B.v1 never
>> be confused with objects from B.v2.  Demanding that only one version of
>> B be loaded is extremely short sighted.  That demands that the author of
>> A be in control of the evolution of both C and B which may never be
>> possible.
> 
> This kind of multi-versioning is not precluded by a cohesive version set in a distribution; in fact it's actually a function of it.  In JBoss Modules for example, there is no actual difference between two versions of one module compared to two distinct modules.  

The goal should be to find nirvana and point Java’s evolutionary path in that direction.  All of the communities around all of these modular build and distribution platforms have picked particular paths because of a limited number of peoples choices to go in that direction.  Now, we have too many choices, none of which are compatible or interact cleanly with each other.  That indicates to me, that there has been “wandering” evolution based on exploration, without real consideration of what would be optimal.  

For any software system evolution, there is an ever widening group of considerations as the complexity evolves.  It’s sort of like a tornado on the ground.  The smaller diameter of the typical depiction of a tornadic wind column tearing stuff up on the ground and flinging it about is like the evolution of a new language, looking for the “hole” or “void” in other languages it can fill.  As you go up the column, the wind patterns stabilize because they are not interacting with the turbulence near the ground.  Midway up the tornadic column of air, you’ll find things mostly hanging together with some things occasionally thrown out.  Near the top, the column of air slows in apparent rotation speed because it is so wide (well an F5 here in Oklahoma is not so slow). 

My analogy is intended to illustrate that early on, there are lots of choices that can be made.  All the other systems that exist today have made those choices and found things that work, and kept some things that are not so great after all.  It would seem much more pragmatic and intelligent to go get some people from every one of the build an distribution systems to come work on this JSR and try and find the nirvana from their perspective.

Yes, this has been delayed for eons.  But, practically, now is not the time to start working on the wrong solution.

> But again it's a distribution problem to ensure that the correct modules link against their correct dependencies and to ensure that such linkage doesn't result in undesirable interactions.  There is to my knowledge no algorithm that can automatically make these kinds of decisions without a polynomial-scale increase in complexity, which at run time is Not Cool.
> 
>> 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 don't think it's a question of caring, nor do I think there's a one-dimensional cleanliness-versus-pragmatic axis that we must place ourselves on.  In other words, this is a bit of a straw man.

I think that many people involved in the evolution of Java (In the distant past Sun, and now at Oracle) don’t really understand, or even perhaps try to understand how frustrated the Java community is, overall, with the way that JSR owners have, and continue to strangle and eliminate contributors who do care.  There are a lot of type-A personalities involved and a lot of "I know exactly what’s needed" (and yes I am putting myself into that camp as an observer who has been around Java from the beginning) and that makes it tough for people to get along.  But practically, we all need to figure out how to make good things actually happen.  

I’m of the opinion that modularity is completely about two things.  One, is fixing the jar: URL mechanism to allow recursive references.  The second is creating an infrastructure that would allow a Java store to appear, complete with libraries where I could release an application dependent on a library in the store, and I could designate when my application was ready to accept a library upgrade.  That would allow my application and that library to be maintained with updates possible, and still allow the user to have a great experience with the software. Modularization should be about fixing the synchronization of all Java applications in a completely closed loop versioning system.

Gregg

>> Yes you can want a pretty world.  Practically, there is no way that you
>> can dictate how people develop software and how it should interact.
>> 
>> Gregg Wonderly
>> 
>> On 2/5/2015 7:00 AM, mark.reinhold at oracle.com wrote:
>>> 2015/2/5 12:40 +0000, david.lloyd at redhat.com:
>>>> I agree that working dependency resolution is a necessity for a working
>>>> software system.  But, it is my opinion that run time is far too late
>>>> for this to occur (and I intend to carry this opinion into the JSR
>>>> working group).  Ultimately it is up to the module distributor to ensure
>>>> that their distribution contains a cohesive module set.  While it is
>>>> possible to efficiently add certain types of validation checks at run
>>>> time, by this time it is far too late to do anything about a violation
>>>> other than just fail.
>>> Broadly speaking, I agree.  At run time a module system should prevent
>>> broken situations such as conflicting module versions.  It need not,
>>> however, attempt to solve them -- that's really hard, and it generally
>>> requires human intervention in order to identify the correct version.
>>> Simply failing in such scenarios (with a good error message, of course)
>>> is perfectly acceptable.
>>> 
>>> - Mark
>>> 
>> 
> 
> -- 
> - DML