On 29/09/2015 16:14, Ron Pressler wrote:
Hi.
The module system leaves the task of version selection, version conflict
resolution and other version-related issues to build tools, but as one of
the maintainers of a launch tool, Capsule <http://www.capsule.io/> — which
is similar to a build tool in many respects -- I can’t quite see how this
should be done, and would appreciate some guidance.
Capsule is interesting, it might be worth exploring how it could work
with jlink too.
:
1. I don’t see a way other than the module path to inform the JVM of the
module graph configuration (such as passing the name of a class that will
create the configuration etc.). A workaround may be to inject an agent that
will be listed first on the command line, have its premain method never
return, and let it parse the rest of the command line, loading the main
module through a custom layer. This may sound like a terrible hack, but
it’s the kind of things tools do, and it might still be less brittle and
hack then shadowing. My question is, is there a better way?
Right, the module path is the way on the command-line to make the
modules observable. There may be many possible configurations that
result from this of course because it depends on the initial module that
you specify and other command line options.
In the API (and you might have found this already) then ModuleFinder is
what needs to be implemented to find modules that are organized
differently or packaged in other ways. A finder can be thought of being
backed by a set of modules, keyed by module name. You specify the
ModuleFinder to Configuration.resolve and it will find the modules using
that finder. The finder is also used to locate modules when doing
service binding. If there is Shade-like re-renaming going on then it can
be transparent. If there are consistency issues (like a module M reading
two modules that both export package P to M) then it will be caught by
Configuration.resolve.
There isn't a way to interpose on the creation of the configuration that
becomes the boot Layer and I think this is what you are asking for.
There's a chicken and egg aspect to this because the VM and module
system need to be initialized before code outside of java.base can be
loaded and executed. This also applies to java agents where you will
find the boot Layer already exists before the agent's premain is
executed. I expect this topic will come up again once the Maven and
Gradle folks start to explore modules as they have repository layouts
that might result in really long module paths. The java launcher has
@argfile support now and this makes it a bit easier but it may still be
a bit more efficient to just provide the set of modules and the initial
module.
-Alan.
