modulepath and classpath mixture

Fri Apr 1 22:51:10 UTC 2016

Rémi,

I think all of us working on Jigsaw have equally shared the experience of figuring out how to do testing in this modular world.

Currently, the solution to your problem is to use javac's -XaddReads option, which is to javac's compilation environment what the launcher's -XaddReads option is to the execution environment.

Just as the runtime provides a family of options to configure the modules is use at runtime,
	-upgrademodulepath -modulepath -addmods -limitmods -XaddReads -XaddExports -Xpatch etc
so too does javac have an equivalent set of options to configure the modules in use at compile time.

The primary additions/differences at compile time:
	-modulesourcepath	(obviously source in not applicable at runtime)
	-system			(when compiling, you can override the default target system)
	-Xmodule		for compiling additional classes to patch into a module

-- Jon

On 04/01/2016 02:55 PM, forax at univ-mlv.fr wrote:
> Hi Jon,
> thanks for taking the time to explain the whole picture, as you know, you are probably the one with most experience about testing in the modular world.
>
> This threads starts with this question, how to do unit testing with Maven when everything is a module, your case 3, so i will focus on that case.
> Here is my question, in case of 3a or 3b, i don't see how to explain to javac how to compile if there are some specific dependencies for the test (that are also modules).
>
> regards,
> Rémi
>
> ----- Mail original -----
>> De: "Jonathan Gibbons" <jonathan.gibbons at oracle.com>
>> À: "Remi Forax" <forax at univ-mlv.fr>, "Alan Bateman" <Alan.Bateman at oracle.com>
>> Cc: "Russell Gold" <russell.gold at oracle.com>, "jigsaw-dev" <jigsaw-dev at openjdk.java.net>
>> Envoyé: Jeudi 31 Mars 2016 03:29:55
>> Objet: Re: modulepath and classpath mixture
>>
>> I have been following this thread, and it strongly reminds me of Joe
>> Darcy's parables of elephants and blind men. [1,2]
>>
>> In this context, the discussion has been about testing, and the
>> underlying presumption that one size fits all.
>>
>> I venture to suggest that one size does /not/ fit all, and that we have
>> to be able to support a wide range of testing paradigms.
>>
>> 1) Some folk will want to do black box testing, with their tests
>> contained in their own first class module, to exercise the code the way
>> that real clients might do
>>
>> 2) Some folk will want to do black box testing, with their test code on
>> the classpath, in the unnamed module, because they don't want to update
>> their test code
>>
>> 3) Some folk will want to do white box testing, using code conventions
>> is widespread use today, where the test code is alongside the code being
>> tested, in the same package.   This generates two sub-cases:   a) is the
>> test code compiled into the module itself, in a special test-specific
>> build, or  b) is the test code dynamically patched into the module
>>
>> 4) Some folk will want to do white box testing, but will be less
>> concerned about the package used to contain the package.  That has the
>> same two sub-cases:    a) is the test code compiled into the module
>> itself, in a special test-specific build, or  b) is the test code
>> dynamically patched into the module
>>
>> Now you take all those scenarios, and cross-product them with issues
>> like, is there a test framework involved, such as JUnit or TestNG, and,
>> where should that framework be placed: can it be an automatic module, or
>> it is sufficient to put the framework on the classpath, in the unnamed
>> module?
>>
>> When you understand all that, then you begin to see the shape of the
>> elephant in the room that is the testing problem.
>>
>> But, to stretch the analogy to breaking point,  it's not the only
>> elephant in the room.  There's another, different, elephant called
>> "strong encapsulation", and there is a strong conflict between the
>> desire for easy white box testing and the desire for strong
>> encapsulation. While the past 20 years of Java have led to easy simple
>> white box testing, leveraging split packages by adding jars onto the
>> class path, we've also seen the the problems that such techniques can
>> lead to ... hence the desire for Project Jigsaw, and the requirement [3]
>> for strong encapsulation.  We have to accept that the better we succeed
>> at strong encapsulation, the harder it will be to use the old ways of
>> white box testing. Conversely, the more we hold to the old ways of
>> working, the less we will succeed at satisfying the goal of strong
>> encapsulation.
>>
>> So, ultimately, the trick is to figure out how to walk the tightrope
>> between the two elephants in the room.  Previously, as a community,
>> we've built tools to help manage the task. Now, it is time for the tools
>> and our practices to evolve, to meet the new demands of testing in a
>> modular world.
>>
>> Do we have all the answers today? Almost certainly not. But I will note
>> one of the unheralded success stories of Jigsaw and OpenJDK. Testing has
>> always been important, and we have managed to keep running almost all of
>> the JDK unit and regression tests with little to no change in
>> functionality in almost all of the tests, and we have started supporting
>> new testing scenarios as well. Looking back at the list I gave at the
>> beginning, support for 1 is coming available, but not yet widely used,
>> many JDK tests use case 2,  JDK has a number of tests that use 3b and
>> 4b, and we have tests that use JUnit and TestNG.
>>
>> So, command line options like -XaddExports, -Xpatch, -Xmodule, etc, may
>> not be pretty, but they can be composed to cover a wide range of testing
>> scenarios, without giving up too much on the goal of strong
>> encapsulation, and that at least is some degree of success.
>>
>> -- Jon
>>
>> [1]
>> https://blogs.oracle.com/darcy/entry/project_coin_elephants_knapsacks_language
>> [2] http://en.wikipedia.org/wiki/Blind_Men_and_an_Elephant
>> [3] http://openjdk.java.net/projects/jigsaw/spec/reqs/
>>