Some suggested patches and improvements

[David M. Lloyd]

On 05/12/2017 09:37 AM, Stephen Colebourne 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.

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