Problematic use of setAccessible

Aleksey Shipilev shade at
Thu Sep 15 05:53:04 UTC 2016

On 09/14/2016 10:52 PM, Claes Redestad wrote:
> On a JDK 9 with patches for the recent jigsaw proposals[1], JMH runs
> into some trouble due to the new behavior around reflective access
> to non-exported types:
> Exception in thread "main"
> java.lang.reflect.InaccessibleObjectException: Unable to make private
> java.nio.charset.Charset accessible: module java.base
> does not "exports private" to unnamed module @78e67e0a
>     at
> java.base/jdk.internal.reflect.Reflection.throwInaccessibleObjectException(
>     at
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(
>     at
> java.base/java.lang.reflect.Field.checkCanSetAccessible(
>     at java.base/java.lang.reflect.Field.setAccessible(
>     at org.openjdk.jmh.util.Utils.guessConsoleEncoding(
>     at org.openjdk.jmh.runner.Runner.createOutputFormat(
>     at org.openjdk.jmh.runner.Runner.<init>(
>     at org.openjdk.jmh.Main.main(

Grrrr. Is there a build where it fails?

> Setting this on the command line works around the issue:
> --add-exports-private java.base/

Somewhat bad: we don't have the JDK version detection logic, and JDK < 9
would reject such an option.

> Better yet: adding something to that effect to the manifest is supported
> and might be a transparent and backwards-compatible solution, e.g., in
> the pom.xml:

This is worse: people run JMH workloads via Java API and their own
builders, bypassing the uberjars with our custom manifests.

Or maybe it is a good time to add Console.encoding() as the public method.


More information about the jmh-dev mailing list