On 05/12/2016 20:13, Martin Buchholz wrote:
Whitebox testing is the most obvious example of code that has a good
excuse for poking inside implementation details.
For running jsr166 tests, I'm happy to report that the following seems
to work:
<jvmarg value="-Xbootclasspath/p:@{classes}" unless:set="modules"/>
<jvmarg line="--patch-module java.base=@{classes}" if:set="modules"/>
+<jvmarg line="--add-opens java.base/java.util=ALL-UNNAMED"
if:set="modules"/>
+<jvmarg line="--add-opens java.base/java.util.concurrent=ALL-UNNAMED"
if:set="modules"/>
+<jvmarg line="--add-opens
java.base/java.util.concurrent.atomic=ALL-UNNAMED" if:set="modules"/>
+<jvmarg line="--add-opens
java.base/java.util.concurrent.locks=ALL-UNNAMED" if:set="modules"/>
It would be nice if there was explicit guidance for authors of tooling
software like test harnesses.
There have been a number of threads on jigsaw-dev on this topic.
Whitebox tests that are in the same package as the API under test (by
convention or because they are testing package-private methods) can be
compiled and run "as if" they are part of the module. This is done with
the --patch-module option, like what you are doing to override the
jsr166 classes in java.base. Code in a module can do "deep reflection"
on any element of any type in its own module so the tests shouldn't have
any issue when they are in the module. That said, there might some
additional command line options needed to allow the test runner invoke
the tests (where the tests are added to the module in a non-exported
package) or where the tests links to the supporting test library
(probably JUnit here). We've worked with many scenarios where everything
is modules or where there is a mix of modules and class path, it can all
be made to work. In time then I hope the test runners will make this
easier but there isn't anything specifically written up yet.
It would be nice if the production software could define test-only
methods (think "checkInvariants()") that could be invoked without
having to resort to reflection. Google has some
use-this-method-in-tests-only tooling that uses annotations, but the
enforcement is external to the jdk. I keep hoping that module systems
would somehow work at the method level instead of the package level,
because we already have visibility keywords like private at the method
level.
If the checkInvariant methods aren't public then the packages that they
are in will needed to be opened to whoever calls them. For the scenario
then qualified exports or qualified opens can be used to export and/or
open specific packages to test modules.
Giving access to internals to legitimate tools while preventing other
uses seems like a Hard Problem. For tools like debuggers or heap
analyzers that really want to see everything, there will be a strong
desire to "disable all module checks". Or maybe the right way is for
users to patch them into java.base? Guidance needed.
We updated the debugger support and the tools APIs to support modules
some time ago. I'm not sure if we have a specific issue in mind but the
debugger support involves JVM TI and JNI on the backend so there isn't
an issue with accessibility. Heap analyzers that are based on the tool
APIs should be fine too, as should tools and agents based on the
instrumentation API (it's even possible for agents that don't know
anything about modules to instrument code in modules).
-Alan
