Problematic use of setAccessible
Claes Redestad
claes.redestad at oracle.com
Thu Sep 15 09:35:46 UTC 2016
On 2016-09-15 07:53, Aleksey Shipilev wrote:
> 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?
No published jigsaw EA build, yet, but patches for the proposals are
in jake:
http://hg.openjdk.java.net/jigsaw/jake/
>
>
>> 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.
Sure, but there'd still be a documented way around it. Maybe we should
catch InaccessibleObjectException[1], print a warning/pointer to
workarounds, then move on with Charset.defaultCharset()?
/Claes
[1] It's quite inconvenient with a new exception type here when we need
to be backwards compatible - catch(RuntimeException ex) and match
ex.getClass().getName() feels like a hack, but works.
>
> Or maybe it is a good time to add Console.encoding() as the public method.
>
> Thanks,
> -Aleksey
>
More information about the jmh-dev
mailing list