modulepath and classpath mixture

[David Hill]

On 3/23/16, 7:01 AM, 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.
We have worked through this white/black box testing classes in JavaFX, While not a perfect solution we have something that seems to work (at least we get the tests to pass anyway :-)

I created a OpenJFX Unit test in Jigsaw TOI in our wiki here <https://wiki.openjdk.java.net/display/OpenJFX/OpenJFX+unit+tests>. While it is specific to the JFX build, there is a lot of detail in there that is general to unit testing and Jigsaw.

There are several keys here.
   1) separate out the white/black box test classes, creating new "shims" (white box classes) as needed. We picked the "test.*" package for the black box tests and refactored all of our unit tests into it.
   2) at build time create a copy of our "core" classes with the white box shims added in so that we have one module override tree
   3) use Xpatch, @addExports so that things can be found

"@addExport" is an argfile usage which makes adding multiline -XaddExport: options reasonable. If you don't know about @argfile, you might want to look at my wiki page just to learn about those :-)

Certainly the solution we have took a lot of rework, and we did debate with the Jigsaw team about several elements of it. But what we ended up with works within the current boundaries.

BTW - any feedback or questions on the TOI would be appreciated.

https://wiki.openjdk.java.net/display/OpenJFX/OpenJFX+unit+tests




> I struggle with that idea.
>
> 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.
>
> 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.
>
> Peter Levart's mail suggested one approach to provide the necessary
> access rights for testing modules. But it still requires publication
> package-by-package. Really, what is needed is a way to express that
> the testing module is intimately connected, perhaps imposing a
> requirement that both are loaded in the same classloader. eg.
>
> module my.mod {
>      fully-exposed-to my.mod.test;
> }
> module my.mod.test {
>      requires my.mod;  // since other end specifies fully-exposed-to,
> this gets full access
>      requires junit;
> }
>
> Is this issue on the list of open issues?
> http://openjdk.java.net/projects/jigsaw/spec/issues/
>
> Stephen


-- 
David Hill<David.Hill at Oracle.com>
Java Embedded Development

"A man's feet should be planted in his country, but his eyes should survey the world."
-- George Santayana (1863 - 1952)