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

[Eric Newcomer]

Reading through this thread it looks like the different views are based on two fundamentally different assumptions: that a module system should start with Java SE/EE and fit within it's design constraints (JBoss) and that a module system should be designed from the ground up, and Java just happens to be used for it's implementation (OSGi). A lot of the back and forth seems to be about how modules fit with current practice in Java rather than the way in which a module system should behave, whether or not it's implemented using Java. 

Eric



On Nov 17, 2011, at 11:31 AM, "David M. Lloyd" <david.lloyd at redhat.com> wrote:

> 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