modulepath and classpath mixture

[Robert Scholte]

On Mon, 07 Mar 2016 13:13:38 +0100, Alan Bateman <Alan.Bateman at 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