October 2015 - jpms-spec-comments

Comment to "The State of the Module System"
by Siegmar Alber 18 Oct '15

18 Oct '15

Hello, I just read "The State of the Module System" (http://openjdk.java.net/projects/jigsaw/spec/sotms/) and found an issue in the section "Implied readability": "… The getParentLogger method is defined in the Logger class, …" As far as I can see, d.getParentLogger() is not defined in the Logger class but returns an instance of the Logger class. I guess thats just a small inaccuracy. While thinking about that an additional question came up for me: Is it already an error to call d.getParentLogger() or does the error just occur when trying to use the returned object as a Logger instance (i.e. calling the info method on it)? In other words: Is it possible to compile e.g. "Object logger = d.getParentLogger();"? -- Thanks and kind regards, Siegmar Alber

1 0

Auto-layering? Layers too specific a mechanism?
by Mike Hearn 07 Oct '15

07 Oct '15

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(a)vinumeris.com> Date: Wed, Oct 7, 2015 at 1:44 PM Subject: Auto-layering? Layers too specific a mechanism? To: jpms-spec-observers(a)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 <http://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.

1 0

Use of modules by build/launch tools
by Ron Pressler 05 Oct '15

05 Oct '15

Hi. I'm posting to this mailing list on Alan Bateman's suggestion, after discussing it on the jigsaw-dev list. The module system leaves the task of version selection, version conflict resolution and other version-related issues to build tools, but as one of the maintainers of a launch tool,Capsule <http://www.capsule.io/> — which is similar to a build tool in many respects -- I can’t quite see how this should be done, and would appreciate some guidance. The problem arises with version conflicts of a transitive dependency on a library that has breaking changes between versions. This is a common occurrence. One notable example is ASM. Suppose I have an application model, A, with the following dependencies: A —> B C —> L@v2 D E M —> L@v1 —> B L@v2 —> B When I build the application, the build tool detects the version conflict, L@v1/v2, and emits an error/warning. At this point the developer tells the build tool to find a solution such that library M will resolve the dependency on L at v1, but all other modules will use L@v2. This is done today using shadowing, namely merging L@v1 into the same JAR file as M, and transforming all classes both in M and L so that L’s packages are renamed. This solution is obviously brittle. For example, it may not work when reflection is involved, and in any event, it is excessive. There is no reason why the same solution (shadowing) would not work with Jigsaw modules, but it seems like Jigsaw could offer a better way, except I see two problems that I’d like to ask for advice on: 1. I don’t see a way other than the module path to inform the JVM of the module graph configuration (such as passing the name of a class that will create the configuration etc.). A workaround may be to inject an agent that will be listed first on the command line, have its premain method never return, and let it parse the rest of the command line, loading the main module through a custom layer. This may sound like a terrible hack, but it’s the kind of things tools do, and it might still be less brittle and hack then shadowing. My question is, is there a better way? 2. Suppose there was a way to create a configuration more complex than a single module path. How would I construct the one I described above? My first though was to have one layer consisting of all modules, and then a child-layer with M —> L@v1. But this doesn’t work as A —> M, and you can’t resolve a Configuration that’s missing a dependency. My next guess was to put all dependencies except M in one layer, then M —> L@v1 in another, and then A in yet another, but this doesn’t work either as A —> L@v2, and the L@v1 would override that. Then I thought of putting M —> L@v1 —> B in the first layer, and then everything else in another, overriding L, but this isn’t quite right as it would result in two versions of B. The only solution, then, is putting M —> L@v1 —> B in the first layer, and then everything else, taking care to override L but not B. This can work, but it may be quite annoying to compute, especially given that my intentions are very simple — resolve everything as you would except resolve L to L@v1 when accessed through M. Shouldn’t there perhaps be a way to modify the graph selectively before final resolution (or some other form of fine-grained control over the graph’s construction)? So, the module system leaves the task of version selection and conflict resolution to build tools — and rightly so — but I don’t see it simplifying the tools’ job or helping them avoid terrible hacks, even though it seems like it could. Shadowing is a solution for the problem of dependency hiding (or dependency encapsulation), which is something the module system is intended to solve. Shouldn't it help with this problem? The requirements document is a bit unclear on the issue; it delegates version selection to build tools -- where it belongs -- and it mentions that multiple versions are supported via dynamic configuration which is intended for containers. Indeed, the way module configurations are arranged -- i.e. with a hierarchy of layers -- makes sense for multi-application containers, but less sense for the problem of dependency version conflict (as explained in the example). But the problem of transitive-dependency version conflict is not discussed, except by hinting that it may not be important enough, because "most applications are not containers and, since they currently rely upon the class path, do not require the ability to load multiple versions of a module". That is not quite accurate. Most applications rely on the classpath *plus* shadowing. A GitHub search finds over 37K *direct* uses of shadowing <https://github.com/search?l=maven-pom&p=1&q=maven-shade-plugin&type=Code&ut…>, and that is a very, very small part of the picture (even if many of those results are projects don't really require it) because shadowing is used by libraries to hide their dependencies, and those libraries are then used by many more projects that don't use shadowing directly. Any project that has even a single transitive dependency that makes use of shadowing is facing the problem of version conflicts (and handles it with this hack). Ron

1 0