modulepath and classpath mixture

[Alan Bateman]

On 08/03/2016 19:13, Robert Scholte wrote:
>
> 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.
If the sources in src/test/java are a completely separate module then 
they will have their own module declaration.

If the tests are instead intended to augment the module, say where the 
tests are in the same package as the code under test, they will not have 
their own module declaration. This means no module-info.java in 
src/test/java. As things currently stand then javac -Xmodule:$MODULE 
will ignore the module-info.java when you compile the sources in 
src/test/java. At run-time then you'll get a warning if there is a 
module-info.class found when patching a module.

So I think you will need to get the module name when compiling the 
tests. You should not need the module name when compiling the code in 
src/main/java of course. The complication for the tests as they are 
being compiled "as if" they are part of the module.

As the tests classes in the same module as the main classes then it 
means the tests have access to all public types in the modules (no 
exports are needed). Furthermore, they are in the same package as the 
main classes then they have access to private package types/methods too.

The final part will be running the tests as the injected test classes 
will have dependences on JUnit or TestNG tests. They module declaration 
doesn't declare that it requires those and this is why we need to 
augment it at run-time with -XaddReads so that it reads the JUnit 
module. There are choices here as to whether JUnit is deployed on the 
class path or module path, it can work as either.

-Alan