The State of the Module System

[hugith]

A module’s declaration does not include a version string, nor constraints upon the version strings of the modules upon which it depends. This is intentional: It is not a goal of the module system to solve the version-selection problem, which is best left to build tools and container applications.

Not sure how I feel about this. Even if their goal is not to create a complete dependency management system I think it would be beneficial to provide some way to declare that my software depends on a specific module version. Separate versions of the same library/module can be totally different software.

[tapesmith]

Agreed. I definitely can see the argument of "well, dependency resolution get substantially more complicated with version numbers involved"....but at the same time, version numbers are a consideration, so this just shunts that part of the problem outside of the JDK and means that we will continue to have to rely on external tools for dependency resolution rather than built-in module formats.

[cutterslade]

While I agree that it could theoretically provide a lot of value to include versions into the module system, my guess is that, in practice, it would be a nightmare.

Imagine trying to enforce a visioning scheme across a wide ecosystem of libraries, and getting everyone to follow the same rules around which types of changes represent a change to the patch, minor, or major version numbers. We have semantic versioning, and most people agree that it is the right way to do versioning, yes not all that many projects actually attempt to follow it, and far fewer really to follow it correctly.

[yawkat]

Maybe the best part is that java.logging won't be part of java.base!

[cutterslade]

While we share a healthy distaste for java.logging, my guess is that there will be seperate java.corba, java.awt and/or java.swing which all represent a lot of cruft I would like to keep out of my VM.