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

[Jonathan Gibbons]

CSR and patch look good to me.

-- Jon


On 05/13/2019 06:02 AM, Jan Lahoda wrote:
> Thanks Alex!
>
> Could I please get a review on the CSR?
>
> https://bugs.openjdk.java.net/browse/JDK-8222396
>
> And also on the patch:
> http://cr.openjdk.java.net/~jlahoda/8220702/webrev.01/
>
> Thanks!
>
> Jan
>
> On 06. 05. 19 21:06, Alex Buckley wrote:
>> 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