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.
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.
-Alan
