RFR: JDK-8220702: compiling in the context of an automatic module disallows --add-modules ALL-MODULE-PATH

[Alex Buckley]

On 4/12/2019 12:03 PM, Alex Buckley wrote:
> On 4/12/2019 5:34 AM, Jan Lahoda wrote:
>> I've started with the CSR here:
>> https://bugs.openjdk.java.net/browse/JDK-8222396
>
> Looks pretty good. I made some edits to record both of your
> single-module and multi-module invocations of javac.
>
> The use case of injecting test code is clear, but the exact connection
> between automatic modules and test code is pretty opaque. Is the goal to
> make the automatic test module read the explicit test module so that the
> former module's code can access the latter module's code? Is the goal to
> make the automatic module read (and therefore test) at least the same
> set of modules as the explicit modules `requires`?

Reviewing the CSR again, it seemed like the key scenario is multiple 
named modules, where for each named module:

1. We don't really care about its relationship with the other named 
modules; but

2. We do care about injecting it with test code, and letting that test 
code read other, completely arbitrary, modules (say, an 
assertion-building library that's been placed on the module path).

I have refactored the CSR to more strongly separate the problem 
(patching an automatic module is possible, but readability is sub-par) 
from the solution (precedent for ALL-MODULE-PATH from the unnamed module 
scenario).

JEP 261 should be updated to explain the awesome power of --patch-module 
at compile time, and that is progressing behind the scenes, but I don't 
think it needs to block JDK-8220702 -- the CSR is "good enough" 
documentation for now.

Alex