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

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Alex Buckley
// Adding jigsaw-dev -- this topic is slightly deeper than it appears.

On 4/9/2019 4:43 AM, Jan Lahoda wrote:
> Currently, when compiling an unnamed module, --add-modules
> ALL-MODULE-PATH adds all modules from the module path to the module
> graph, so that the unnamed module can refer to them.

(See also http://openjdk.java.net/jeps/261#Root-modules plus the section
"Root modules" in the java.lang.module package spec.)

> When compiling a named module, this option is not allowed, as it would
> be confusing, as it cannot modify the dependencies of the named module.
>
> But, when compiling a code in the context of an automatic module using
> --patch-module, e.g.:
> javac --module-path <automatic-module> --patch-modules
> <automatic-module-name>=<dir> ...
>
> The --add-modules ALL-MODULE-PATH is still disallowed, but it may make
> sense to use it, as it may affect the set of classes available for the
> sources that are being compiled. Compiling in the context of an
> automatic module may be useful esp. in when patching multiple modules at
> once (which is supported by --patch-module), e.g. to build tests. (Seems
> that also at least the use of javadoc in Maven may lead to a similar
> setting as well, see the JBS bug.)

JEP 261 doesn't discuss compiling code "in the context of an automatic
module", and javac's reference guide doesn't imply that `--patch-module`
supports it, but it is clearly a plausible and useful thing to do, so
thanks for calling it out.

There is a question to be answered: When the compiler compiles code in
an automatic module (due to the code being observed in a directory that
is specified to --patch-module), then what is the _default set of root
modules_ for the automatic module?

I expect the answer is: the same as the default set of root modules for
the unnamed module. And actually, for the `javac` invocation shown
above, which is single-module mode, this answer is given in the "Compile
time" section of JEP 261
(http://openjdk.java.net/jeps/261#Compile-time). Unfortunately, the
answer is only accidentally right, because the section did not envisage
compiling code in an automatic module; for the `javac` invocation above,
the section says "source files will be compiled as members of the
unnamed module".

So, there's another question to be answered: Does `javac` support
compiling code in an automatic module in single-module mode, or
multi-module both, or either? Once we know this, we can update the
"Compile time" section and answer the set-of-root-modules question.

> The proposal is to allow the --add-modules ALL-MODULE-PATH option when
> compiling code in the context of an automatic module.

I support this proposal, subject to the questions raised above.

A CSR will be needed; in addition to specifying the things mentioned
above, it can clarify the description of ALL-MODULE-PATH w.r.t. when it
can be used at compile time. Currently, the description seems unsure
about when it can be used.

(For reference, the text: "As a final special case, at both run time and
link time, if <module> is ALL-MODULE-PATH then all observable modules
found on the relevant module paths are added to the root set.
ALL-MODULE-PATH is valid at both compile time and run time. This is
provided for use by build tools such as Maven, which already ensure that
all modules on the module path are needed. It is also a convenient means
to add automatic modules to the root set.")

Alex

> Proposed patch: http://cr.openjdk.java.net/~jlahoda/8220702/webrev.01/
> JBS: https://bugs.openjdk.java.net/browse/JDK-8220702
>
> What do you think?
>
> Thanks,
>      Jan
Reply | Threaded
Open this post in threaded view
|

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

Alan Bateman
On 10/04/2019 19:51, Alex Buckley wrote:
> :
>
> There is a question to be answered: When the compiler compiles code in
> an automatic module (due to the code being observed in a directory
> that is specified to --patch-module), then what is the _default set of
> root modules_ for the automatic module?
>
> I expect the answer is: the same as the default set of root modules
> for the unnamed module.
This isn't the case at run-time. If the initial module is an automatic
module, and there are no additional roots specified with --add-modules,
then the automatic module will be the sole root. Whether it is patched
or not via --patch-module doesn't change that of course. The module
descriptor created for the automatic module will require (mandated)
java.base so minimally the automatic module + java.base will be in the
module graph. Run-time does service binding and java.base uses a lot of
services so the module graph will have ~25 modules when using a JDK
run-time image. The addition of service binding at run-time probably
means few would notice the difference but if the right answer is the
default set of root modules when we should probably change run-time too.

-Alan
Reply | Threaded
Open this post in threaded view
|

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

Alex Buckley
In reply to this post by Alex Buckley
On 4/10/2019 2:51 PM, Jonathan Gibbons wrote:

> On 4/10/19 11:51 AM, Alex Buckley wrote:
>> There is a question to be answered: When the compiler compiles code in
>> an automatic module (due to the code being observed in a directory
>> that is specified to --patch-module), then what is the _default set of
>> root modules_ for the automatic module?
>>
>> I expect the answer is: the same as the default set of root modules
>> for the unnamed module.
>
> I would not expect the fact that you're compiling code in one or more
> automatic modules to have any effect on the module graph. The fact that
> the definitions of some types have been "patched in" using source code
> via --patch-module is (or should be) irrelevant.

I'm not sure how anyone compiles code as if in an automatic module,
since the automatic module is solely a JAR file, but Jan suggests that
it's possible to patch an automatic module's content with the source
files being compiled. So, I looked in JEP 261 to see how javac would
treat those source files:

"If a module descriptor in the form of a module-info.java or
module-info.class file is specified on the command line [NO], or is
found on the source path [NO] or the class path [NO], then source files
will be compiled as members of the module named by that descriptor and
that module will be the sole root module. Otherwise if the --module
<module> option is present [NO] then source files will be compiled as
members of <module>, which will be the root module. Otherwise [I GUESS
WE'RE HERE] source files will be compiled as members of the unnamed
module, and the root modules will be computed as described above."

Alex
Reply | Threaded
Open this post in threaded view
|

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

Jonathan Gibbons

On 4/10/19 3:07 PM, Alex Buckley wrote:

> On 4/10/2019 2:51 PM, Jonathan Gibbons wrote:
>> On 4/10/19 11:51 AM, Alex Buckley wrote:
>>> There is a question to be answered: When the compiler compiles code in
>>> an automatic module (due to the code being observed in a directory
>>> that is specified to --patch-module), then what is the _default set of
>>> root modules_ for the automatic module?
>>>
>>> I expect the answer is: the same as the default set of root modules
>>> for the unnamed module.
>>
>> I would not expect the fact that you're compiling code in one or more
>> automatic modules to have any effect on the module graph. The fact that
>> the definitions of some types have been "patched in" using source code
>> via --patch-module is (or should be) irrelevant.
>
> I'm not sure how anyone compiles code as if in an automatic module,
> since the automatic module is solely a JAR file, but Jan suggests that
> it's possible to patch an automatic module's content with the source
> files being compiled. So, I looked in JEP 261 to see how javac would
> treat those source files:
>
> "If a module descriptor in the form of a module-info.java or
> module-info.class file is specified on the command line [NO], or is
> found on the source path [NO] or the class path [NO], then source
> files will be compiled as members of the module named by that
> descriptor and that module will be the sole root module. Otherwise if
> the --module <module> option is present [NO] then source files will be
> compiled as members of <module>, which will be the root module.
> Otherwise [I GUESS WE'RE HERE] source files will be compiled as
> members of the unnamed module, and the root modules will be computed
> as described above."
>
> Alex

It sounds like JEP 261 should be updated with more info about patching
modules, since "you are not here" where you guess we are.

At compilation time, --patch-module allows any content to be "patched
in" to any module in the module graph. The content may be provided in
source form or compiled form. In either case, the context for any names
mentioned in the content is determined by the module being patched, and
its dependencies.

-- Jon

Reply | Threaded
Open this post in threaded view
|

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

Jan Lahoda
On 11. 04. 19 0:19, Jonathan Gibbons wrote:

>
> On 4/10/19 3:07 PM, Alex Buckley wrote:
>> On 4/10/2019 2:51 PM, Jonathan Gibbons wrote:
>>> On 4/10/19 11:51 AM, Alex Buckley wrote:
>>>> There is a question to be answered: When the compiler compiles code in
>>>> an automatic module (due to the code being observed in a directory
>>>> that is specified to --patch-module), then what is the _default set of
>>>> root modules_ for the automatic module?
>>>>
>>>> I expect the answer is: the same as the default set of root modules
>>>> for the unnamed module.
>>>
>>> I would not expect the fact that you're compiling code in one or more
>>> automatic modules to have any effect on the module graph. The fact that
>>> the definitions of some types have been "patched in" using source code
>>> via --patch-module is (or should be) irrelevant.
>>
>> I'm not sure how anyone compiles code as if in an automatic module,
>> since the automatic module is solely a JAR file, but Jan suggests that
>> it's possible to patch an automatic module's content with the source
>> files being compiled. So, I looked in JEP 261 to see how javac would
>> treat those source files:
>>
>> "If a module descriptor in the form of a module-info.java or
>> module-info.class file is specified on the command line [NO], or is
>> found on the source path [NO] or the class path [NO], then source
>> files will be compiled as members of the module named by that
>> descriptor and that module will be the sole root module. Otherwise if
>> the --module <module> option is present [NO] then source files will be
>> compiled as members of <module>, which will be the root module.
>> Otherwise [I GUESS WE'RE HERE] source files will be compiled as
>> members of the unnamed module, and the root modules will be computed
>> as described above."
>>
>> Alex
>
> It sounds like JEP 261 should be updated with more info about patching
> modules, since "you are not here" where you guess we are.

Yes, I think JEP 261 may need updates. I'd say this is somewhat
unforeseen interaction between automatic modules and --patch-module.

When patching a (named) module (or a set of named modules), that module
(or modules) become the root module for javac, and the ordinary module
graph building algorithm is then used to build the module graph. So the
set of modules in the module graph may be different from the set of the
modules in the module graph when compiling source in the unnamed module.

Jan

>
> At compilation time, --patch-module allows any content to be "patched
> in" to any module in the module graph. The content may be provided in
> source form or compiled form. In either case, the context for any names
> mentioned in the content is determined by the module being patched, and
> its dependencies.
>
> -- Jon
>
Reply | Threaded
Open this post in threaded view
|

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

Alex Buckley
On 4/11/2019 1:19 AM, Jan Lahoda wrote:
> Yes, I think JEP 261 may need updates. I'd say this is somewhat
> unforeseen interaction between automatic modules and --patch-module.
>
> When patching a (named) module (or a set of named modules), that module
> (or modules) become the root module for javac, and the ordinary module
> graph building algorithm is then used to build the module graph. So the
> set of modules in the module graph may be different from the set of the
> modules in the module graph when compiling source in the unnamed module.

OK. It sounds like (i) single-module mode supports source files being
compiled as if members of a named module (the module being patched), and
(ii) multi-module mode supports source files being compiled as if
members of named modules (the modules being patched). Great.

Broadly, JEP 261 is correct when it says this in "Root modules":

-----
Otherwise, the default set of root modules depends upon the phase:
- At compile time it is usually the set of modules being compiled (more
on this below);
-----

where "below", it is correct for multi-module mode:

-----
The set of root modules is the set of modules for which at least one
source file is specified.
-----

but incorrect for single-module mode: (assuming javac is invoked as
shown in your first mail)

-----
Otherwise source files will be compiled as members of the unnamed
module, and the root modules will be computed as described above.
-----

JEP 261 is the ultimate source of truth for the module system, from
which all tutorials, blogs, books, etc derive. It's very hard to infer
from it that javac supports compiling source as if in a patched module.
That's why a CSR to record what javac does (either with no --add-modules
or with --add-modules=ALL-MODULE-PATH) will be so valuable. In advance
of that, can you share some detailed invocations of javac using
--patch-module in single-module and multi-module mode?

Alex
Reply | Threaded
Open this post in threaded view
|

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

Christian Stein
On Thu, Apr 11, 2019 at 8:30 PM Alex Buckley <[hidden email]>
wrote:

> [...] In advance
> of that, can you share some detailed invocations of javac using
> --patch-module in single-module and multi-module mode?
>

I'm not sure if this helps in any regards -- here [1] is a draft PR
that adds explicit module descriptors to all JUnit 5 modules.

This PR uses javac in multi-module mode and --patch-module
to access the already (with --release 8) compiled classes of
each module. The "src/modules/build.jsh
<https://github.com/junit-team/junit5/pull/1848/commits/f8ed9ad6c37bfcf9512f2747874d3974750b9d16#diff-374344d9b9ebdc3b396ebd6c9dc24b94>"
jshell script allows
an OS-agnostic execution of the javac command.

Hope that helps,
Christian

[1]
https://github.com/junit-team/junit5/pull/1848/commits/f8ed9ad6c37bfcf9512f2747874d3974750b9d16
Reply | Threaded
Open this post in threaded view
|

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

Alex Buckley
On 4/11/2019 12:00 PM, Christian Stein wrote:
> I'm not sure if this helps in any regards -- here [1] is a draft PR
> that adds explicit module descriptors to all JUnit 5 modules.
>
> This PR uses javac in multi-module mode and --patch-module
> to access the already (with --release 8) compiled classes of
> each module.

Thanks Christian. Ultimately you're invoking javac like so:

javac --patch-module org.junit.platform.commons=
                      junit-platform-commons/build/classes/java/main
       --module-version 1.5.0-SNAPSHOT
       src/modules/org.junit.platform.commons/module-info.java

where it is interesting to see --patch-module indicating the putative
content of a module before the module-info.java file which declares the
module into existence has been compiled!

You even get the benefit of error-checking for module-info.java, e.g.,
that its `exports` refer to packages which truly exist in the module. I
suppose if you just put junit-platform-commons/build/classes/java/main
on the --module-path then you would not get this checking.

The first point for using --patch-module at compile time goes to Jan for
building tests as if members of automatic modules; you get the second
point for building module declarations as if members of ... well,
themselves.

Alex
Reply | Threaded
Open this post in threaded view
|

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

Jan Lahoda
In reply to this post by Alex Buckley
On 11. 04. 19 20:28, Alex Buckley wrote:

> On 4/11/2019 1:19 AM, Jan Lahoda wrote:
>> Yes, I think JEP 261 may need updates. I'd say this is somewhat
>> unforeseen interaction between automatic modules and --patch-module.
>>
>> When patching a (named) module (or a set of named modules), that module
>> (or modules) become the root module for javac, and the ordinary module
>> graph building algorithm is then used to build the module graph. So the
>> set of modules in the module graph may be different from the set of the
>> modules in the module graph when compiling source in the unnamed module.
>
> OK. It sounds like (i) single-module mode supports source files being
> compiled as if members of a named module (the module being patched), and
> (ii) multi-module mode supports source files being compiled as if
> members of named modules (the modules being patched). Great.
>
> Broadly, JEP 261 is correct when it says this in "Root modules":
>
> -----
> Otherwise, the default set of root modules depends upon the phase:
> - At compile time it is usually the set of modules being compiled (more
> on this below);
> -----
>
> where "below", it is correct for multi-module mode:
>
> -----
> The set of root modules is the set of modules for which at least one
> source file is specified.
> -----
>
> but incorrect for single-module mode: (assuming javac is invoked as
> shown in your first mail)
>
> -----
> Otherwise source files will be compiled as members of the unnamed
> module, and the root modules will be computed as described above.
> -----
>
> JEP 261 is the ultimate source of truth for the module system, from
> which all tutorials, blogs, books, etc derive. It's very hard to infer
> from it that javac supports compiling source as if in a patched module.
> That's why a CSR to record what javac does (either with no --add-modules
> or with --add-modules=ALL-MODULE-PATH) will be so valuable. In advance
> of that, can you share some detailed invocations of javac using
> --patch-module in single-module and multi-module mode?

I've started with the CSR here:
https://bugs.openjdk.java.net/browse/JDK-8222396

Consider a directory "path" that contains "automatic.jar", which does
not have a module-info.class, and "explicit.jar" which has
module-info.class. The a compilation in multi-module mode might look
like this:
$ javac -d out --patch-module automatic=test/automatic/src
--patch-module explicit=test/explicit/src --module-path path
--module-source-path dummy
test/automatic/src/automatic/AutomaticTest.java
test/explicit/src/explicit/ExplicitTest.java

A compilation in single-module mode might look like:
$ javac -d out --patch-module explicit=test/explicit/src --module-path
path test/explicit/src/explicit/ExplicitTest.java

Jan

>
> Alex
Reply | Threaded
Open this post in threaded view
|

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

Alan Bateman
On 12/04/2019 13:34, Jan Lahoda wrote:

> :
>
> Consider a directory "path" that contains "automatic.jar", which does
> not have a module-info.class, and "explicit.jar" which has
> module-info.class. The a compilation in multi-module mode might look
> like this:
> $ javac -d out --patch-module automatic=test/automatic/src
> --patch-module explicit=test/explicit/src --module-path path
> --module-source-path dummy
> test/automatic/src/automatic/AutomaticTest.java
> test/explicit/src/explicit/ExplicitTest.java

I think this mean that "automatic" reads "explicit" and all other
modules that the recursive enumeration of "explicit" brings to the
graph. This AutomaticTest can refer to any of the public types in any of
the packages exported by the modules. There was a suggestion in one of
the mails that the set of default modules (all those in the run-time
image that export an API) would also be resolved but I don't think this
is the case here.

-Alan
Reply | Threaded
Open this post in threaded view
|

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

Alex Buckley
In reply to this post by Jan Lahoda
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`?

Alex
Reply | Threaded
Open this post in threaded view
|

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

Alex Buckley
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
Reply | Threaded
Open this post in threaded view
|

Re: 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
Reply | Threaded
Open this post in threaded view
|

Re: 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
Reply | Threaded
Open this post in threaded view
|

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

Jonathan Gibbons
In reply to this post by Jan Lahoda
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