jmh code might be unreproducible

One of the travis builds failed on the reproducibility test without apparent relation to the change (I think). Makes me think maybe it just surfaced there:
https://travis-ci.org/bazelbuild/rules_scala/jobs/497218553
```
< 47c3d415c9e5dbe424c573d08f40da1e bazel-bin/test/jmh/test_benchmark_compiled_benchmark_lib.jar
< 47c3d415c9e5dbe424c573d08f40da1e bazel-bin/test/jmh/test_benchmark.runfiles/io_bazel_rules_scala/test/jmh/test_benchmark_compiled_benchmark_lib.jar
1501a1500
> 4f5fa74aa94da701176f042a1e47c841 bazel-bin/test/jmh/test_benchmark_codegen_resources.jar
5393a5393,5394
> d9a26e038170d9e26c593555af311b79 bazel-bin/test/jmh/test_benchmark_compiled_benchmark_lib.jar
> d9a26e038170d9e26c593555af311b79 bazel-bin/test/jmh/test_benchmark.runfiles/io_bazel_rules_scala/test/jmh/test_benchmark_compiled_benchmark_lib.jar
7596d7596
< ef6ee9a44b47c199f47ee962eaf89e7f bazel-bin/test/jmh/test_benchmark_codegen_resources.jar
```
@johnynek wdyt?

Start with the Travis job and the reproducibility test output for test/jmh, comparing the hashes and paths under bazel-bin/test/jmh. Determine why the compiled benchmark and codegen resources differ between runs, then make the reproducibility test pass consistently.

Written by the indexing model from the issue text.