I was going through a fantastic talk by Alex and nearly all the things he spoke made sense to me except for the given thing.


In a nutshell how does module manage versions. If I have a module v1 with a method with different implementation, a separate module v2 with a same method signature and return but a different implementation, how will the tooling resolve the dependency?


2 Answers 2


It won't, dependency-resolution is a non-goal for the Java Platform Module System (source):


  • Multiple versions — It is not necessary to support more than one version of a module within a single configuration.
  • Version selection — The process of configuring a set of developer modules and JDK modules, in any phase, need not consider more than one version of any particular module.

In other words, we see no need to build yet another dependency-resolution mechanism. Maven, Ivy, and Gradle have all tackled this difficult problem. We should leave it to these and other build tools to discover and select a set of candidate modules for a given library or application; the module system need only validate that the set of modules selected by the build system satisfies each module’s dependences and version constraints.

  • the Modules system appears to be largely for the open source community to provide glorified versions of public. This is less a candidate for large Enterprise grade applications as modularity can still be managed using Maven, etc. Does Modules solve the "when is a String not a String" problem encountered in "classpath hell"? This is more readily encountered when deploying multiple ears to a server.
    – dan
    Commented Dec 6, 2022 at 17:21

I can’t quite come up with proper link explaining this but adding module versioning is a non-goal for project Jigsaw.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.