Refresh of module system coming to jdk9/dev soon

[Martin Buchholz]

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 <Alan.Bateman at oracle.com>
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
>