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

[Alex Buckley]

On 5/13/2019 6:02 AM, Jan Lahoda wrote:
> Could I please get a review on the CSR?
>
> https://bugs.openjdk.java.net/browse/JDK-8222396

Added myself as a reviewer.

Alex

> 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