I plan to keep on using reflection to access implementation details in tests, using --add-opens as necessary. That does require having control over the commandline, or using a module-aware test framework that takes care of that for you (like jtreg).
We still don't have a solution to the inheritDoc problem - how to inherit doc comments from javadoc in superclasses in modules. The tools I was thinking of that might need to be jigsaw aware were jol and jmh. On Tue, Dec 6, 2016 at 4:22 AM, Alan Bateman <[email protected]> wrote: > 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 >
