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.
