Why not get rid of versions?
forax at univ-mlv.fr
forax at univ-mlv.fr
Thu Mar 24 23:19:34 UTC 2016
----- Mail original -----
> De: "Paul Benedict" <pbenedict at apache.org>
> À: forax at univ-mlv.fr
> Cc: "ML OpenJDK Jigsaw Developers" <jigsaw-dev at openjdk.java.net>
> Envoyé: Jeudi 24 Mars 2016 21:28:15
> Objet: Re: Why not get rid of versions?
> 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?
This is something we may have explained poorly, at startup time, all the modules you have in the modulepath are resolved, then when the main() is executed, any codes can create a new layer, loads its own modules from wherever it wants, using the resolution algorithm it wants, using any information it wants (like by example the metadata stored in the module-info.class). So in fact, in this scenario, there are two resolution algorithms, the jigsaw one for the modules in the modulepath, the one from a module system like OSGi.
> [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-March/007021.html
> Cheers,
> Paul
cheers,
Rémi
More information about the jigsaw-dev
mailing list