Some suggested patches and improvements

Michael Rasmussen michael.rasmussen at zeroturnaround.com
Fri May 12 16:18:06 UTC 2017


On 12 May 2017 at 17:37, Stephen Colebourne <scolebourne at joda.org> wrote:
> On 12 May 2017 at 01:43, David M. Lloyd <david.lloyd at redhat.com> wrote:
>> 1. Layer primitive: addExports() - mirrors the existing Module.addExports()
>> method for ModuleLayer.Controllers
>> 2. Layer primitive: addUses() - mirrors the existing Module.addUses() method
>> for ModuleLayer.Controllers
>> 3. Layer primitive: addPackage() - allows ModuleLayer.Controllers to add
>> packages to a module after it has been defined
>
> Are these a good idea? I don't know. What I do know is that the use
> cases for them seem to be focussed on low-level coders and framework
> writers, which is a very small subset of all Java developers, and a
> group who can work around difficulties.
>

All of these live on ModuleLayer.Controller, a class used for
controlling a module layer, that should only be accessible to the code
creating that layer. Meaning an API minded exactly for those low-level
coders and writers!

In the case of addExports and addUses, the functionality is already
present through other means, via the corresponding methods on Module,
or even via the instrumentation API. And since you are controlling the
Layer, you are probably also in control of the classloader(s) in which
the modules are defined, meaning it is trivial to define a class into
the module to gain access to the methods on Module. Having these
methods available on the Controller, seems like a much nicer and
cleaner solution, than having to define bridge classes in all modules
in order to accomplish it.

As for addPackage, as pointed out elsewhere in this thread, it's a bit
more tricky...

/Michael


More information about the jigsaw-dev mailing list