How should a build/launch tool best make use of modules?

[Alan Bateman]

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.