modulepath and classpath mixture

[Stephen Colebourne]

On 30 March 2016 at 14:45, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> The thread here has meandered a bit but I think the scenario under
> discussion is tests for a module that need to nestmate with the module under
> test. The tests are in their own test tree. The tests are compiled
> separately from the module they test and may have additional dependences
> (such as on TestNG or JUnit for example). When compiling or running then the
> tests need to access public types in non-exported packages and maybe package
> private members too.

Yes, plus there is a need for one set of  tests to depend on another
set of tests - ie. tests can be an artifact.

> The support for this has been in jake for a long time
> but involves command line options that many developers or build environments
> won't immediately grok. In particular the tests have to be compiled "as if"
> they augment the already compiled module - that is what javac -Xmodule is
> about. There is no need to co-locate source files or class files of course.
> When run then the -Xpatch option is what brings the tests and the module
> classes together. If we get the tools right then most developers won't ever
> see this of course.

This is perhaps a solution that works, but it comes across as highly
esoteric. Two different command line flags, augmenting/patching
modules. What I see is a nightmare to explain.

And while tools can make things easy, it is inadvisable for the design
for running something as basic as tests to be so complex that it
cannot practically be done without tools.

What I see as a better solution is the same approach as I argued for
with optional dependencies - enhancing the syntax of module-info.java
to avoid the need for command line flags

Stephen