Converting plain JARs to Java modules

[Alan Bateman]

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.

-Alan.