Compilation feedback and version question
scolebourne at joda.org
Wed Oct 28 20:50:26 UTC 2015
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
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.
On 28 October 2015 at 18:57, Stephen Colebourne <scolebourne at 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 at 9.0
> java.compact1 at 9.0
> java.compact2 at 9.0
> java.compact3 at 9.0
> java.compiler at 9.0
> java.corba at 9.0
> But when I look at the JDK source module-info.java file:
> 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".
More information about the jigsaw-dev