Problematic use of setAccessible

[Aleksey Shipilev]

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 java.io.Console.cs accessible: module java.base
> does not "exports private java.io" to unnamed module @78e67e0a
>     at
> java.base/jdk.internal.reflect.Reflection.throwInaccessibleObjectException(Reflection.java:414)
> 
>     at
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:196)
> 
>     at
> java.base/java.lang.reflect.Field.checkCanSetAccessible(Field.java:171)
>     at java.base/java.lang.reflect.Field.setAccessible(Field.java:165)
>     at org.openjdk.jmh.util.Utils.guessConsoleEncoding(Utils.java:205)
>     at org.openjdk.jmh.runner.Runner.createOutputFormat(Runner.java:106)
>     at org.openjdk.jmh.runner.Runner.<init>(Runner.java:87)
>     at org.openjdk.jmh.Main.main(Main.java:43)

Grrrr. Is there a build where it fails?


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

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.

Thanks,
-Aleksey