Converting plain JARs to Java modules
Alan.Bateman at oracle.com
Wed Nov 9 02:20:51 PST 2011
On 09/11/2011 08:51, Peter Kriens wrote:
> I have seen Alan's demo of converting poms to Jigsaw modules on JavaOne. I recall that Alan had to fixup most of the poms manually to make this work for Jigsaw? Even after fixing them up, there was no link into the type system or were these dependencies verifiable, you still had to hope that the poms were correct.
> The problem is that module dependencies, like poms, introduce an alternate namespace which is fully disconnected from the Java type system. This requires manual maintenance and opens a large space for errors that are impossible with package dependencies.
> Package dependencies are directly connected the Java type system and therefore imports can be automatically calculated from the code, creating a chain of verification.
There wasn't any manual editing of POMs. The demo was real in that it
connected to the specified repository (I think we specified a URL to
maven central) to locate the requested artifact, downloaded its POM and
the POMs of all of the transitive dependencies, worked out what needed
to be downloaded, generated a module-info.class for each one and then
installed them as modules in the specified module library.
Converting artifacts from maven repositories to modules isn't without
its issues . As I'm sure you know, POMs tend to specify specific
versions of their dependencies which periodically results in conflicts.
It's easy to find examples where an application ends up depending on
several different versions of commons-io or log4j or other commonly used
libraries. Maven has various "strategies" for resolving these, the
default as I understand it, being where it chooses the "nearest
declaration" (essentially the linear class path). Jigsaw detects these
conflicts at install when generating the configuration for the
application module and so installation of the application module (the
module with the entry point) correctly fails. In the demo we did have a
check box called "Resolve Conflicts" to resolve conflicts with the same
strategy and I think I remarked a couple of times that installing
modules in this manner would result in running with something that is
unlikely to have been tested and highly unsuitable for installing into a
module library that is used by other applications.
There are several other issues too. One annoying one is artifacts that
contain classes in packages that are exported by JDK modules. Other
issues included JAR files with duplicate entries, JAR files with classes
that fail verification, and other garbage like this.
I think it's too early to say exactly how we will integrate with Maven
repositories. There is clearly a need (and a requirement) to be able to
download and install artifacts from maven repositories as if they were
modules. It's easy to envisage updating "jmod add-repo" to allow a URL
to a maven repository be specified but it needs a bit more thinking
about some of the issues first.
As regards POMs that have incorrect dependency information then I think
that needs consideration too. As was mentioned earlier in the thread
then static analysis of the class files could help. It's not going to
detect all issues, reflection usages, etc. Ultimately though one would
hope that that once we have a Java Module System that the artifacts
uploaded to these repositories will that module declarations.
More information about the jigsaw-dev