modulepath and classpath mixture

[Alan Bateman]

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