Versioning in the java platform module system - proof of concept
Tom De Wolf
tom.dewolf at aca-it.be
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 oracle.com>:
> On 01/01/2018 18:14, Tom De Wolf wrote:
> > I am working out a proof of concept to use the module version property
> > 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.
> > 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).
More information about the jigsaw-dev