Auto-layering? Layers too specific a mechanism?

Wed Oct 7 11:55:23 UTC 2015

Sorry, just realised that the -observers list specifically says that nobody
may be reading it. Resending to the comments list
---------- Forwarded message ----------
From: Mike Hearn <hearn at vinumeris.com>
Date: Wed, Oct 7, 2015 at 1:44 PM
Subject: Auto-layering? Layers too specific a mechanism?
To: jpms-spec-observers at openjdk.java.net
Currently Jigsaw seems set to not solve the issue of conflicting versions
of common libraries like Guava or language runtimes, except via a layering
mechanism. The JSR says:
"It is the responsibility of build tools and container applications to
configure module paths so as to avoid version conflicts; it is not a goal
<https://openjdk.java.net/projects/jigsaw/spec/reqs/02#version-selection> of
the module system to address the version-selection problem."
I don't fully understand what build tools are meant to do in the case of
dependency tree conflicts. The best Maven can do currently is the
convergence plugin, which just warns you about potential problems. But it
cannot solve them.
Layers *do* seem to solve this problem, by allowing different versions of
the same module to co-exist in the same program. But it seems expected that
ordinary applications won't benefit from this, and only app containers or
apps with a plugin mechanism will need it.
I believe this must be based on the assumption that developers have more
control over their dependency trees than they really do.
I am by no means a large scale Java developer. I maintain a few libraries
and a few apps, all open source. Yet I routinely encounter cases where I
(could) end up with two versions of the same library in my app's dependency
tree, just through the normal act of using open source code.
Common cases are:
   - Guava
   - Language runtimes like Scala, Kotlin, etc
   - Widely used annotation JARs
This can result in apps becoming frozen in time .... adding a feature
requires a new version of library A, but library A requires a new version
of B, and that would introduce a conflict with library C. Often your only
choice is to go and bug the maintainer of C and ask them to upgrade as
well, resulting in slow moving and complicated internet-wide dependency
upgrades.
If every module had its own layer/classloader for internal (non public)
required modules, this problem would solve itself automatically, and
there'd only be issues in the case where two modules exporting the same
package were actually directly depended on by the same module.
But it seems that currently, doing this would require some sort of third
party add-on to the module loader mechanism. That'd be unfortunate.