OK, I can see the version is added at packaging time. And I think I see why, but still pondering it.
Just to note that my experiments of the last 2 hours suggest that "java -listmods" does not show user modules in its output, only JDK modules: java -mp jmods -listmods where "jmods" is a subdirectory of the directory the command is run from and where this command java -mp jmods -m org.joda.convert correctly complains that there is no main class in my module. My experiments also only worked with modular jar files. The jmod generated files were not recognized as modules at all. Finally, I had my module-info.java in the wrong folder initially (at the org.joda.convert package level, rather than the root). However, it got picked up and compiled into the root of the output classes folder. I guess this is expected, but I found it confusing. It might be better to insist that module-info.java must be at the root, and stop javac if it is found in another folder. Stephen On 28 October 2015 at 18:57, Stephen Colebourne <scolebou...@joda.org> wrote: > I can confirm that the current EA build > 1.9.0-ea-jigsaw-nightly-h3660-20151022-b86 allowed a successful build > using maven (with tests) of the OpenGamma test case, which is a step > forward from when I last tried it. > > When running "java -listmods" I get outpuy including this: > > java.base@9.0 > java.compact1@9.0 > java.compact2@9.0 > java.compact3@9.0 > java.compiler@9.0 > java.corba@9.0 > > But when I look at the JDK source module-info.java file: > http://hg.openjdk.java.net/jigsaw/jake/jdk/file/1b632228f7e5/src/java.base/share/classes/module-info.java > It does not contain the version number "9.0". > > Where is the version coming from? It is weird to see the version > number so closely associated with the module in -listmods when so much > of the mood music of the current Jigsaw work is that the version is > "not our problem guv". > > Stephen
