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

[David M. Lloyd]

On 11/16/2011 01:05 PM, Peter Kriens wrote:
> On 16 nov. 2011, at 19:23, Brian Pontarelli wrote:
>> Are you talking about build time here? In practice transitive
>> dependencies can always be avoided at build time. If you are
>> talking about runtime, transitive dependencies are definitely
>> required. I'm not sure exactly what your JPA vs. Eclipse Link
>> example is getting at.
 >
> There is type coupling and instance coupling. Interfaces break the
> transitive type coupling but then require that you bind an instance
> for that interface in runtime, there is a trade off.
> Spring/Guice/CDI/Services, etc all handle this instance coupling.
> With a module system, packages type-decouple you from an
> implementation module just like an interface type decouples a class
> from its dependencies. In the Eclipse Link example, my code is not
> type coupled to Eclipse Link, it is only type coupled to its
> specification package javax.persistence. This allows the deployer to
> choose either Eclipse Link or OpenJPA they both provide the
> implementation to the javax.transaction package. However, my code is
> not having a type coupling on either leaving flexibility to the
> deployer.
>
> So we make a trade off between type decoupling and runtime
> complexity. This is the same trade off we make in IOC/DI engines,
> annotations, and factories.

But I don't see why m2p gives this coupling any better than m2m?  I can 
just as easily have a javax.transaction module with m2m as I could have 
a package with m2p.

In a static module repository, there are really only two ways to choose 
an implementation of some given API: statically, such that there is only 
one implementation for an API which is globally accessed at the API's 
module "address", or at runtime, where the user selects their desired 
implementation based on their own dependencies or other selection tools. 
  There is no special mechanism which becomes available solely due to m2p.

>> Again, are you talking about build time or runtime? Also, are you
>> suggesting that Java determine your dependencies automatically
>> including the version? Or is this merely to help developers find
>> missing dependencies and remove unused dependencies?
> If you compile class com.bar.Foo that refers to com.bar.Bar then the
> Foo.class and Bar.class file contain all their type dependencies and
> by implication their package dependencies. The version of the package
> can then for example be found from package-info.java.
>
> This technique is used extensively in bnd, an open source library
> used in Eclipse, IDEA, ant, maven, SBT, and others. It reads the
> class files in a JAR and generates the OSGi dependency information
> automatically.

This doesn't actually help.  The user already *knows* what their 
dependency is - i.e. the javax.transaction API *module*, which is listed 
in their IDE dependencies as well as in their build - but now they must 
also employ special tooling in order to have the runtime module system 
figure it out too.  This is a significant "impedance mismatch", to use a 
popular metaphor.

-- 
- DML