Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
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?
Thanks!
It won't, dependency-resolution is a non-goal for the Java Platform Module System (source):
Non-requirements
- 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.
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.
I can’t quite come up with proper link explaining this but adding module versioning is a non-goal for project Jigsaw.
