Versioning in the java platform module system - proof of concept

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Versioning in the java platform module system - proof of concept

Tom De Wolf
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:

https://devcreativity.wordpress.com/2017/12/29/semantic-versions-in-java-9-modules-as-a-safety-net/

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?

Thanks in advance for any helpful and insightful reply! Any thoughts,
suggestions, remarks on my proof of concept itself are also more than
welcome.

Tom De Wolf
Reply | Threaded
Open this post in threaded view
|

Re: Versioning in the java platform module system - proof of concept

Alan Bateman
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:
>
> https://devcreativity.wordpress.com/2017/12/29/semantic-versions-in-java-9-modules-as-a-safety-net/
>
> 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

Reply | Threaded
Open this post in threaded view
|

Re: Versioning in the java platform module system - proof of concept

Tom De Wolf
Alan,

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
module-info?

Thx

Tom

Op di 2 jan. 2018 om 09:06 schreef Alan Bateman <[hidden email]>:

> 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:
> >
> >
> https://devcreativity.wordpress.com/2017/12/29/semantic-versions-in-java-9-modules-as-a-safety-net/
> >
> > 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
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Versioning in the java platform module system - proof of concept

Alan Bateman
On 02/01/2018 17:07, Tom De Wolf wrote:
> :
>
> 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 module-info?
The module version is derived from the name of the JAR file. If the JAR
file is named spring-core-5.0.0.M1.jar then the module version will be
"5.0.0.M1". All the details are in the ModuleFinder spec. javac doesn't
derive a module version so there isn't a version string to record at
compile-time.

-Alan