On Mon, 07 Mar 2016 13:13:38 +0100, Alan Bateman <alan.bate...@oracle.com> wrote:

On 06/03/2016 14:01, Robert Scholte wrote:
Hi,

I've asked for some feedback and there seems to be concerns with split packages when there are two or more modules on the module path that export the same package. Unless I misunderstand the issue, I'd say you have the same problem with -addmods. If you add mod1 and mod2, which both export the same package, you have exactly the same issue, right?
Yes, although at least if you specify the module names to -addmods then you are being explicit as to the additional modules to resolve. The issue with -addmods ALL-NAMED (or what the token is) is that it will resolve all modules that can be found via the application module path and so would need to be used with great care.


I can only speak for Maven how it wants to use it. Only the modules used to compile the src/main/java sources will end up on the modulePath in this case. So the set of modules has already been validated, kind of.


When talking about exports it made me realize there's probably another issue: only the exported packages of the "main"-module are accessible, right? Since src/test/java has no module-info, the -Xpatch is useless. An idea that comes to my mind is something like -mainModule <arg>, where are either a jar or directory containing module-info. All its classes can be accessed by the classes on the classpath, all other modules keep their package access restrictions.
I don't think I understand the issue here. Using -Xpatch doesn't change the module declaration or export. It can be used to override or augment the module content, it just can't override the module declaration. It can be used in conjunction with -XaddReads and -XaddExports to read additional modules or export additional packages. For example, if a patch adds types to a new package then you could export that package with -XaddExports. If the patch injects tests into an existing package then those tests might have new dependences and requires compiling or running with -XaddReads:$MODULE=junit for example.

This is how I thought that -Xpatch would work in short: the module-info in src/main/java and src/test/java have both the same modulename. The module-info in src/test/java specifies the extra required modules (like junit). With -Xpatch the test-classes have access to the non-exported main-classes too.


-Alan

thanks,
Robert

Reply via email to