Module ABI versioning

Nicolai Parlog nipa at
Sun Sep 20 08:57:02 UTC 2015

Hash: SHA256


I can come up with two ugly workarounds (see below) for dependency
hell as described by Mike. If other solutions exist, it would be great
if someone pointed them out.

If no less hacky alternatives arise, it looks like Jigaw would indeed
not keep its informal (!) promise to alleviate dependency hell.

At build time:

The build tool would have to identify the dependency on two
conflicting versions. It would then create artificial modules (with
'requires public') that do include the version in their name, e.g. and Finally, it would
alter the dependent modules' module-info.class files to include these

This means that the deployed modules actually differ from the ones
available in public repositories. It also breaks when the modules are
signed (which, as far as I see, is currently not possible).

At run time:

A library could offer the ability to start an application in some
module constellation and then reflectively alter the module graph
(maybe utilizing layers) so that all dependencies on different
versions are correctly represented.

This would require manual or automatic configuration based on the
problematic versions. It also means that the two different versions
can be distinguished by the module system which in turn requires the
artificial modules described above.

 so long ... Nicolai

On 18.09.2015 21:56, Mike Hearn wrote:
> I'd like to appeal for a reconsideration on the stance on module 
> versioning, specifically, I'd like to ask for the simplest/most
> basic possible versioning scheme (a single number) to be included
> in module metadata.
> My use case is a library like Guava. It hits the sweet/sour spot
> for jar hell:
> 1. Very widely used by both apps and libraries 2. Iterates rapidly 
> 3. Releases are not backwards compatible
> This can result in dependency deadlocks where upgrading one library
> is impossible because it depends on Guava N, yet you're also using
> another library that uses Guava M, and the two versions are not
> compatible. Modules would fix this, except for the inability to
> distinguish the N and M modules.
> One can argue, perhaps reasonably, that if two versions of a module
> export classes with the same names but which aren't compatible then
> the modules should have different names instead, i.e. an ABI
> version should be included in the module name. Whilst this would
> work, it seems somehow ad hoc.
> In the native code world this problem is solved for a long time
> already. UNIX libraries do indeed include their ABI version in
> their "soname", but it's done in a standardised way and every DSO
> built with the normal tools includes an ABI version (

- -- 

PGP Key:

        a blog about software development
        Free and Open Source Software for the City of Dortmund


Version: GnuPG v2


More information about the jpms-spec-observers mailing list