modulepath and classpath mixture

[Alan Bateman]

On 23/03/2016 11:01, Stephen Colebourne wrote:
> On 23 March 2016 at 07:21, Alan Bateman <Alan.Bateman at oracle.com> wrote:
>> If they are in the same class loader and package as
>> the code they are testing (the norm in Maven) then they need to compiled as
>> if they are part of the module.
> I struggle with that idea.
If types T1 and T2 have the same defining loader and both types are in 
the same package then they are in the same module. T1 can't be module M1 
and T2 in a different module M2.

(I shudder the thought of it being different or attempting to change 
what default/package access means after all these years.)

>
> To me, tests are very definitely not part of the module. To me, they
> are very clearly a separate module, one that uses the base module
> (separate tree of code, separate dependencies, separate compilation
> phase). In maven, there is even the possibility for one testing module
> to depend on another testing module, a very useful feature.
You can of course develop tests in their own modules, this should be 
painless for black-box testing.

White-box testing is more complicated of course as such tests need to 
nestmate with the module internals they are testing. If people are 
testing package private classes or methods today then those test classes 
are in the same loader/package as the code they are testing. There are 
several discussions points in the mails here but I believe it is the 
scenario that Robert is trying to get working with Maven. It seems more 
of a convention though, it may be that many tests aren't really white 
tests and they could like in their own test.* packages and other modules 
without difficulty.

>
> The only special case about testing modules is that they are given
> full access to everything in the underlying module. Forcing test code
> to be embedded within the actual module just because the module design
> doesn't allow any other option is flawed IMO.
There isn't anything forcing the test sources to be the same source tree 
as the classes they are testing. Tests that directly make use of module 
internals can be compiled separately, have dependences beyond what the 
original module requires, and be packaged in their own artifact. When 
running then the -Xpatch option brings them together. If the tools can 
make this easy for average developers then it might not be too bad.

-Alan.