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
