Module ABI versioning

[Nicolai Parlog]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

 Hi,

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
versions.

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).
> 

- -- 

PGP Key:
    http://keys.gnupg.net/pks/lookup?op=vindex&search=0xCA3BAD2E9CCCD509

Web:
    http://codefx.org
        a blog about software development
    http://do-foss.de
        Free and Open Source Software for the City of Dortmund

Twitter:
    https://twitter.com/nipafx

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJV/nTYAAoJEMo7rS6czNUJ91MP/R4PhtDlL+Hy3zcV3Ql5HuhG
aJNrJHODWBIa0TqePmsKNYnMx63+mjvk5a8mc3Wi0mnU8Yw0QSmAqKVfYnJ8Hrp5
i5YQeG57mIAW3jhaPYLDhercMgj9wFFF6RLJWSk2UMNW5S2Ac8VJjteMBdWoGihs
IhjS0ZZkBBScNmQvMI7cEEFbeoPuLsDc8S3Lu/Y8EZcpFLKc9KjdjeLYkbrxUeB0
YND3sLvtTbpNosBcdsqDN0k813YJbBX1GVKE5L9lMyImkRdiiR4SQm8+bGzdBq/B
RZj06swf8/43ljogjxPipD3uqDxwnxMisqyOJqOwUyO/7oF8IiP9qp9kRUwCr091
w60OGWt+laXN0sg591liS4xvQDFR5FNkxlW5L30UI7h6K4XhbFD3ikWFdhWFdAzu
Y7/lFmaYe4en33j7wqRhnevK1mn/BUZtMjMkAxs9c4sALHhblAHADAeCiK5r4qcx
TfRspS2lV8H9SgCGKVw1DN50VZ4qfkK4Pkp7hKEF/A4ebRsmDVKLiGNiBRP9iDME
N4KjO5RwoXSf69ZYM8LDBCwzFaqvJtTmA4hiZ32McpCZU2nTDMIxwJaTLlDkXY/X
aU01sx8ORa92EzDGg0Qa9KzA/7Tvum/GA81upAS3I+5LcEGwNBt3wAyQgVRQWL3w
LBaP8WqIJW5EFoWYYHW3
=Rbee
-----END PGP SIGNATURE-----