Versioning in the java platform module system - proof of concept

Tom De Wolf tom.dewolf at
Tue Jan 2 17:07:25 UTC 2018


Thx for the reply. If javac does it then it would be solved transparently
in 1 place.

What I don't understand is the reasoning why the
module.getDescription().version() then returns a version for an automatic
module like sprint.core? it is not an explicit module on which javac can do
its magic, so where is that version information stored when there is no



Op di 2 jan. 2018 om 09:06 schreef Alan Bateman <Alan.Bateman at>:

> On 01/01/2018 18:14, Tom De Wolf wrote:
> > I am working out a proof of concept to use the module version property
> and
> > the version of a ‘requires’    in a useful manner. Details and a link to
> > github can be found on:
> >
> >
> >
> > However, I stumbled on behaviour I don’t completely understand:
> > - printing out the module.getDescription().version() showed a non-empty
> > value for the jdk modules, explicit modules which got the version through
> > ‘jar --module-version’, and automatic modules like spring.core
> > - as I understand the Requires.compiledVersion() gets a value when the
> > dependency module has a version in module.getDescription().version()
> >
> > The latter is seen when requiring explicit modules, however requiring an
> > automatic module does not fill in the compiledVersion? Why is that, even
> > when the module.getDescription().version() shows a value (e.g.
> spring.core)?
> >
> > What is used for an automatic module such as spring.core to show
> > 5.0.0.RELEASE as version?
> >
> Requires::compiledVersion returns the module version if it is recorded
> in the module-info.class. javac has chosen to record the version of
> dependences when they are explicit modules. It doesn't record (or know
> anything about) the version of automatic modules at this time. It
> potentially could. Alternatively a build tool could record it (it
> doesn't have to be javac).
> -Alan

More information about the jigsaw-dev mailing list