Testing Jigsaw modules

[Alan Bateman]

On 01/06/2016 14:06, Gunnar Morling wrote:

> Hi,
>
> Are the already best practices and recommendations when it comes to testing
> Jigsaw modules?

Not yet but definitely an important document or FAQ to write.

One command-line option to get familiar with is -Xpatch. You can use 
this when compiling or running the tests so that it is "as if" the tests 
are part of the module under test. That will allow the tests to 
instantiate public types that aren't in exported packages. It also means 
you can have tests in the same package as the classes under test - this 
allows testing of say package private methods or non-public classes.

I expect in time that the test runners will need to add support for 
modules. For the JDK tests then we use the jtreg test harness and it has 
been updated to work with modules, partly by means of a helper that 
allows it to do the setup needed for the tests. So it will be a bit 
awkward for a time, particularly where TestNG it looking to run tests 
that aren't in exported packages.

> :
>
> 4) Hibernate Validator reflectively accesses types from the user's
> application in order to do its job. These classes are not necessarily part
> of the user module's API, e.g. they might wish to put Bean Validation
> constraints to an internally used model type. For that to work, IIUC, the
> user needs to add qualified exports of these internal packages to Hibernate
> Validator. Is that correct?
This is #ReflectiveAccessToNonExportedTypes [1] on the JSR issues list. 
For now, yes, user modules need to export those packages.

-Alan.

[1] 
http://openjdk.java.net/projects/jigsaw/spec/issues/#ReflectiveAccessToNonExportedTypes