Why package deps won't work (Was: Re: Converting plain JARs to Java modules)

[Eric Johnson]

On 11/15/11 6:06 PM, David M. Lloyd wrote:
> As with the equivalent situation on an operating system distribution, 
> the long term goal is always to phase out old versions and introduce 
> new versions over a period of time which is managed by a social 
> process. This type of setup has been proven to work in a number of 
> operating system distributions to date, and seems to work well for our 
> case as well.

The logical conclusion from this, though is that with future JDKs, each 
Linux distributor will have their own modularization of the JDK, so as 
to fit better with their package system, or their version definition, or 
the legacy accommodations that they've made. Wouldn't we all be better 
off if the "official" modularization of the JDK could mostly be used 
as-is, and only tweaked around the edges by distributions?

The situation we ran into as an actual use case with OSGi, and the point 
I think Peter was making, is that if you use M2P dependencies, then you, 
as the modularization distributor, can make changes to the core modules 
without that fanning out to the entire dependency tree, because now you 
can move package X to module Y from original module O, and no dependent 
modules need to change.

If you just use M2M dependencies, then when you try to remodularize for 
whatever reason, and do the same package move, then you have unpleasant 
options. Either you make a bad compromise for compatibility (O now 
depends on Y), or you have to update all the dependent modules. Yuck, or 
yuck.
>
> Like the operating system case, I believe that run-time dependencies 
> are the domain of the module distributor.  The dependencies are often 
> slightly varied depending on who is installing the library, where, and 
> why.  I think it's better to maintain a simple system which is 
> flexible enough to be customized by distribution than to try to come 
> up with a centralized or globalized dependency scheme.  Hard realities 
> like licensing, implementation selection, and defective software will 
> make a pure globalized scheme unworkable.  Take the simple division of 
> philosophy between Debian and Ubuntu or Fedora, where licensing 
> ideology makes a substantial difference in what is distributed and how.

Hmmm. "runtime dependencies are the domain of the module distributor". 
Maybe we're just arguing terminology?

I say runtime dependencies are sometimes the domain of the *deployer*, 
and to me, that's not the same as a module distributor (which I 
interpret as my Linux provider, or enterprise software provider). 
Example: If my application requires an implementation of the 
javax.xml.parsers API, as an application developer, there are at least 
three possibilities: (a) determined by the OS distribution, (b) 
determined by other components of the system that feel a need to 
constrain this, or (c) specifically determined by my launch 
configuration. I might, as an example of the latter, at least from my 
IDE, wish to run test suites using a variety of different 
implementations of the API.

If I start recording M2M dependencies, I might be over-constrained, and 
complete stuck if some existing module happens to include both 
javax.xml.parsers, as well as an implementation of said APIs (as they 
used to do!).

-Eric.