Some suggested patches and improvements

[Stephen Colebourne]

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.

> 4. Make run-time cycle checking optional

My opinion is that run-time cycles are inevitable. The proposed
solutions (refactoring to API vs Impl) is not particularly good in an
open source context. I'm also concerned that "requires static"
(optional dependencies) also naturally leads to cycles

But the question at this point is whether it is worth the effort to
try and live without cycles for this release - after all, no-one wants
cycles in their design. Since there is a workaround, via the
low-level module/layer code, it feels like we should be willing to
take the punt and try to live without cycles in 9 keeping it under
review to add in 10.

> 5. Add optional class loader isolation for modules on the module path

Again, my opinion is that the isolation of modules is insufficient in
Jigsaw and that hidden packages will sometimes be very messy. However,
the only tool available to solve this appears to be classloaders, and
they have plenty of flaws themselves. While opt-in isolation appears
tempting, I'd prefer to wait and see a better solution in a later
version. Maybe the answer is to deprecated class loaders and come up
with something better!


Given where we are, I think my preference is to see a JDK 9 release
soon rather than end the JSR over these issues.

Stephen