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

[Jan Lahoda]

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