As discussed in Chapter 3, Handling Inter-Module Dependencies, one important feature of most module systems is conspicuously absent in Java modularity--that of module versioning and version management. If you've dealt with build and packaging tools in the Java ecosystem such as Maven and Gradle, you might have come across the fact that all their library artifacts have version numbers associated with them. With Maven or Gradle, when you establish a dependency on another artifact or library module (and I'm using the word module loosely here), you not only have to specify its name and coordinates, you also have to specify its version number.
With Java module dependencies, there's no way to specify version-based dependency. The requires syntax, requires <module-name>; just accepts the module name, and not the version. For example, you can specify that your module depends on the google.guava module. But you cannot specify that it depends on version 1.5.2 of google.guava. The Java Platform Module System specification clearly states that versioning isn't one of the goals of the module specification. The idea is to leverage the existing build tools and containers to solve this problem, which they have already done in earlier versions of Java.
If you are not familiar with what the build tools such as Maven or Gradle do, their job in pulling in dependencies can be classified into two parts. I am simplifying, of course, but at a high level, these tools do the following:
- Provide a way for each project to specify what other libraries they are dependent on.
- Pull in those libraries during build and adding the JARs to the classpath so that the project that needs them has the necessary libraries available to use. These JARs are typically downloaded from a central repository based on the dependencies and version numbers specified.
Because tools such as Maven and Gradle does #2 above, it is essential for them to have all the details--not only which library to download, but also which version of the library to download. Remember, it needs to download the right jar from a repository with thousands of libraries with multiple versions of each. The Java module system does #1 but not #2, but not for the purposes of fetching or downloading artifacts from somewhere. It just assumes the modules are already there! This is why versions do not apply here. The version of the module you have in the module path is the version that will be used.
This is where something like Maven fundamentally differs from JPMS. The build tools deal with build artifacts--downloading and assembling packaged jar file distributables. A Java module is not a build-time artifact, but a compile time and runtime artifact. Maven concerns with making sure the right dependencies are assembled. The Java Module system is concerned with compile and runtime integrity of binaries that have already been assembled.
This allows the option of using build tools such as Maven or Gradle to download the right versions of modular JAR files and dependencies, thereby leaving the fully prepared set of modules available in the module path for the module system to then take over and use.
We'll look at Maven integration with Java 9 modular applications in much more detail in Chapter 12, Using Build Tools and Testing Java Modules.