Remi, thanks for your response. You stated a lot of useful information. If you don't mind, I will just quote snippets to prevent the email from getting too lengthy. Thanks.
You wrote: > This is part where we can not do exactly the same thing at compile time > and at runtime, because doing the module resolution like maven does > at runtime will make the application startup so slow that nobody will use it. Agreed. You wrote: > Currently, the only way to create a Layer is by using the API at runtime > (it may change but that's another story), so a tool like OSGi (or JBoss Module > or JavaEE module) will create a Layer using this API and knows how to > interpret the version of a module because it's the OSGi code that will > control the layer and will add the module into the layer. Now this is where things get confusing for me. Since the JSR requirements came out, it's been pretty clear that the Version is not part of any "requires" statement because the version is not supposed to be involved in dependency resolution. By the time the JDK is loading modules into the runtime, all the correct versions have been selected -- not by the JDK, but by whatever assembly mechanism that packaged the application. Maybe this is Maven, for example. So now I am reading emails this week where people are going to "interpret" the version. If you're talking about "interpreting" it for runtime dependency resolution, then you have a conflict with the original Jigsaw requirements (or least my understanding of them). Your phrasing was "interrop with module systems that does their resolution at runtime" and "query the version of a module at runtime" [1]. Either Version is involved at resolution at runtime or it isn't... or now it is sometimes? [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-March/007021.html Cheers, Paul
