On 12 May 2017 at 01:43, David M. Lloyd <david.ll...@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
