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
