Why not get rid of versions?

[Alan Bateman]

On 24/03/2016 19:05, Paul Benedict wrote:
> Remi, I would like to engage you more on this topic, especially on your
> statement: "ease the interrop with module systems that does their
> resolution at runtime"
>
> Let's say I have a project that relies on Apache Commons Collections. My
> project is dependent on version [2.0, 3.3) -- that's the physical version
> string in my POM.
>
> Now if the build tool is meant to bake the version into the class file,
> there are two choices here: "[2.0, 3.3)" which is a version range OR the
> actual version range resolved at build time.
I'm not sure which build tool is storing version constraints in class 
files but just to say that we haven't defined any meta data or class 
file attributes for this. Early exploratory phases of Project Jigsaw did 
have support for a lot of this but this is ancient history now.

All we have is support for tools to add a version at packaging time. You 
can try this with the jar tool now. At runtime then you can get the 
module version if you want and you'll see it show up in places for 
troubleshooting reasons, like stack traces. There is early support for 
hashes to tie very tightly coupled modules but that is almost a separate 
topic.

So if a tool is indeed storing version constraints then it's not 
something that the module system knows anything about.

-Alan.