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

[Ron Pressler]

I don't think I entirely understand your answer. Do you mean that the
suggested method for solving transitive-dependency conflicts in Java 9 is
still (the brittle) shadowing?

Also, the somewhat-less-hacky hack I was suggesting with agents isn't to
change the boot layer itself, but to leave it empty (aside from the agent's
module), and manually load the application through a new layer (or
multi-layer) configuration (which may be annoying to compute due to the
second problem).

Ron

On Thu, Oct 1, 2015 at 1:48 PM, Alan Bateman <Alan.Bateman at oracle.com>
wrote:

> 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.
>
>