Mailing-List: contact dev-help@ant.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Ant Developers List" <dev@ant.apache.org>
From: Tomas Zezula <tomas.zezula@oracle.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: JUnitTask + JDK9 question
Message-Id: <BBC416D5-5553-42DC-A797-E9F93118E24A@oracle.com>
Date: Fri, 1 Apr 2016 14:41:11 +0200
To: Ant Developers List <dev@ant.apache.org>
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))

Hi All!

In the JDK 9 module environment running unit tests is more complex task =
than it was in the classpath mode.
The problems of test compilation and execution are nicely described in =
the following thread =
http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-March/thread.html#6=
587 on the jigsaw-dev mailing list. Also there is lots of different test =
scenarios as described in
=
http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-March/007152.html.

Basically there are two problems:
The first problem is that modules enforce module boundaries, only =
exported packages are seen
from other modules.
The second problem is the module readability - dependency among modules.


 The tests can be executed in the following ways:

1st) In classpath mode - the current way JunitTask executes tests
All the libraries, project artifacts, junit and test classes are on =
classpath. In this scenario the classpath artifacts become a part of the =
unnamed module. There is no problem with module boundaries or =
readability as all artifacts are a part of a single module (unnamed =
module). However the tests do not run in the same environment as the =
product which executes the project in its own module. Also services =
registered in the module-infos are not available in the ServiceLoader. =
This is probably not acceptable.

2nd) Blackbox testing.
The tests have its own module, in other words there is a module-info in =
the test sources in addition to module-info in sources. All the =
libraries, project artifact, test classes and junit are on modulepath. =
The test=E2=80=99s module-info requires the project module (sources) and =
junit end exports all test packages to make them accessible by junit. =
The limitation is that in such a setup only classes exported by the =
project module can be tested (unless =
-XaddExports:sourceModule/sourcePackage=3DtestModule is passed to the =
JVM). The -addmods:testModule JVM option is needed to make testModule =
active and readable by junit. Next limitation is that the test classes =
cannot be in the same packages as tested sources because split packages =
are not supported by the module system.
The module readability graph: =
http://wiki.netbeans.org/wiki/images/a/a9/Blackbox_module_path.png

The complete java command line is:
java -mp build/test/classes:build/classes/:lib/lib.jar:lib/junit.jar  =
-addmods:testModule  -m junit/org.junit.runner.JUnitCore app.AppTest

3rd) Whitebox testing - probably most common
The tests are inlined into the source module.
All the libraries, project artifact, test classes and junit are on =
modulepath (there is an option to keep junit on classpath which I will
explain later). As the test classes are in the same module as project =
sources there is no problem with module boundaries and readability among =
project sources and tests. The test packages need to be exported to be =
accessible by junit by -XaddExports:sourceModule/testPackage=3Djunit and =
made readable by JUnit -XaddReads:sourceModule=3Djunit -addmods =
sourceModule.
The module readability graph: =
http://wiki.netbeans.org/wiki/images/c/ca/Whitebox_module_path.png

The complete java command line is:
java -mp build/classes/:lib/lib.jar:lib/junit.jar =
-Xpatch:sourceModule=3Dbuild/test/classes -addmods sourceModule =
-XaddExports:sourceModule/testPackage=3Djunit =
-XaddReads:sourceModule=3Djunit -m junit/org.junit.runner.JUnitCore =
app.AppTest


There is also a possibility to keep the junit.jar on the classpath =
rather than on the modulepath. In this case junit becomes a part of an =
unnamed module, when on modulepath it becomes an automatic module. The =
same JVM options are required, only the -XaddReads:sourceModule=3Djunit =
changes to -XaddReads:sourceModule=3DALL-UNNAMED. The disadvantage of =
this solution is that unit test can read the unnamed module which =
contains junit but may contain other unwanted jar files on classpath. =
The only advantage of these solution is that it does not need module =
execution (-m JVM option).
The module readability graph: =
http://wiki.netbeans.org/wiki/images/3/38/Whitebox_class_path.png

The complete java command line is:
java -mp build/classes/:lib/lib.jar -cp lib/junit.jar =
-Xpatch:sourceModule=3Dbuild/test/classes -addmods sourceModule =
-XaddExports:sourceModule/testPackage=3Djunit =
-XaddReads:sourceModule=3DALL-UNNAMED org.junit.runner.JUnitCore =
app.AppTest


The JUnit task needs to be extended to support all three scenarios.
There are two possibilities how to extend the JUnitTask:

1st) Minimal needed changes
Just add a modulepath to JUnit task. When junit library is not found on =
the classpath but found on the module path do the modular execution by =
-m junit/<mainclz> rather than classpath execution. The user is =
responsible for passing the -XPatch, -XaddExports, -XaddReads, -addmods =
JVM options. Options like -XaddExports are harder to calculate as they =
require list of test packages. But it can be done by the following =
pathconvert:

<dirset id=3D"packages" dir=3D"build/test/classes" includes=3D"*"/>
<pathconvert refid=3D"packages" property=3D=E2=80=9Cexports.cmd=E2=80=9D =
pathsep=3D" ">
   <chainedmapper>
       <flattenmapper/>
       <globmapper from=3D"*" to=3D"-XaddExports:${module.name}/*=3Djunit"=
/>
   </chainedmapper>
</pathconvert>


2nd) Extend Junit task to automatically set the -XPatch, -XaddExports, =
-XaddReads, -addmods options for modular execution.
This will require adding more attributes to JUnit task (path to test =
classes to do the -XPatch, ability to disable the automatic options).

As the 2nd solution is a superset of the 1st one I will start with it.
Any thoughts and comments are welcome
Thanks,
=E2=80=94 Tomas=

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org