Refresh of module system coming to jdk9/dev soon

[Alan Bateman]

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