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
