On 05/12/2017 09:37 AM, Stephen Colebourne wrote:
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.
I appreciate your confidence in our abilities. :)
However I think these changes will directly lead to a better user
experience for those people who are using such containers. And they
don't impact those who don't. A "majority rules" sort of metric doesn't
always give a clear idea of cost/benefit, especially when you consider
that while most people don't *develop* containers or frameworks, most
users of Java *use* them. Frameworks which work smoothly are a key
ingredient for apps which work smoothly.
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.
It's true, cycles sound bad. But as a point of fact, at run time
they're not demonstrably harmful, and in fact worrying overmuch about
cycles detracts from clean design principles: I have an ABI that
conforms to a particular behavioral contract; it should not matter how I
meet that contract (and in particular, whether I do so by way of a
series of other contracts that ultimately may be used by things which
use *my* ABI is a completely uninteresting distraction).
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.
What workaround are you referring to? Without this patch, there's no
way I can assemble an application with cycles on the module path without
the JVM blowing up.
If you're referring to the addReads() API, don't think it's fair to
users to require that a container or manual module management be
employed in these cases, nor to forbid theses users from using jlink.
Think about *why* this is being enforced at run time; what benefits will
the user receive when they get this error? What about costs? With this
change, the cost can be mitigated, while the benefits (whatever they may
be) are retained.
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!
Among the EC members who voted no, this was the most oft-cited technical
concern (as far as I could find). I don't think it is realistic to
expect a change of vote without addressing the voters' primary concerns;
what I'm trying to do is to create a compromise solution.
Experience with end user applications running under our modular system
and OSGi over the past 5+ years seems to indicate that most software can
cope with class loader isolation with few or no changes. I would be
highly skeptical that a piece of software being modularized is likely to
survive the reflection changes, new service loader behavior, etc., yet
somehow fail due to class loader isolation; nevertheless, making it
opt-in means that this risk would be minimized.
Given where we are, I think my preference is to see a JDK 9 release
soon rather than end the JSR over these issues.
The JSR must be resubmitted within 30 days of the conclusion of the
original vote; my hope is to get enough small changes in there that at
least the *key* concerns are addressed so that the required 2/3 majority
vote is likely.
But my purpose of posting these changes here is not to create debate
over procedure or politics, but rather to discuss the technical
qualities of the patches: Are they acceptable? If not, why not, and
what changes would be needed to make them acceptable, or what
alternative approaches could solve the same problems in a better way?
--
- DML
