Module ABI versioning
nipa at codefx.org
Sun Sep 20 08:57:02 UTC 2015
-----BEGIN PGP SIGNED MESSAGE-----
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.
com.google.guava_18_0_0 and com.google.guava_16_0_1. 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 (libfoo.so.0).
a blog about software development
Free and Open Source Software for the City of Dortmund
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
-----END PGP SIGNATURE-----
More information about the jpms-spec-observers