11

I thought that JPMS doesn't support module version. However, when I do java --list-modules I have the following output:

java.activation@9
java.base@9
java.compiler@9
java.corba@9
java.datatransfer@9
java.desktop@9
java.instrument@9 
....

So, I can't understand what this @9 is. Is this version or what? If JPMS supports module version, can I set in module-info of module A, that module A requires module B of certain version?

Daniel Widdis
  • 8,424
  • 13
  • 41
  • 63
Pavel_K
  • 10,748
  • 13
  • 73
  • 186

3 Answers3

8

I can't understand what this @9 is. Is this version or what?

Yes, it is the version of the module.

If JPMS supports module version, can I set in module-info of module A, that module A requires module B of certain version?

No, you cannot refer a specific version of a module in another module's declaration. I believe this was always clearly mentioned in The State of the Module System#Module Declarations

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 as 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.

Naman
  • 27,789
  • 26
  • 218
  • 353
  • However, no build tool will solve the problem of 2 modules requiring other version of another module... – 9ilsdx 9rvj 0lo Jun 04 '19 at 06:44
  • @9ilsdx9rvj0lo: The OSGi module framework for Java supports this! See [this answer](https://stackoverflow.com/a/27744286/452775). – Lii Aug 15 '20 at 17:26
7

To shed more light on the existing @9 information:

JVMS 9 includes a field module_version_index in the Module_attribute structure, i.e., the class file format supports storing a version string of a module, even a requires_version_index has been defined, but I am not aware of any specification that relates to evaluating this version, rendering this data purely informative at this point.

More information about the current status (as of Java 9 GA) regarding module versions can be found in the Issue Summary. The format of versions is defined in ModuleDescriptor.Version API.

Stephan Herrmann
  • 7,963
  • 2
  • 27
  • 38
1

The Java module system has no intention to solve the version selection or verification problem.

However, it does support adding version information to a module jar that is available through the Module API.

Similarly, a ‘requires’ clause on another module will contain the version of the dependency it was compiled against. A prerequisite is that the other module needs to contain the version number.

Having both these versions available through an API makes it possible for other frameworks to verify if an application composed from different modules has compatible versions (e.g. based on semantic versioning).

In a maven build the following usage of the java ‘jar’ tool allows to add the project.version to the modular jar:

<plugin>
            <groupId>org.codehaus.mojo</groupId>
            <artifactId>exec-maven-plugin</artifactId>
            <version>1.6.0</version>
            <executions>
                <execution>
                    <id>add-version-to-jar</id>
                    <phase>package</phase>
                    <goals>
                        <goal>exec</goal>
                    </goals>
                    <configuration>
                        <executable>jar</executable>
                        <workingDirectory>${project.build.directory}</workingDirectory>
                        <arguments>
                            <argument>--update</argument>
                            <argument>--verbose</argument>
                            <argument>--module-version</argument>
                            <argument>${project.version}</argument>
                            <argument>--file</argument>
                            <argument>${project.build.finalName}.jar</argument>
                            <argument>-C</argument>
                            <argument>${project.build.outputDirectory}</argument>
                            <argument>.</argument>
                        </arguments>
                    </configuration>
                </execution>
            </executions>
</plugin>

A more detailed description and code showing this can be found on

tomdw
  • 51
  • 4