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