RFR: 8245309: Re-examine use of ThreadLocalCoders in sun.net.www.ParseUtil

[Julia Boes]

On Tue, 15 Sep 2020 09:40:06 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> test/micro/org/openjdk/bench/java/net/ThreadLocalParseUtil.java line 61:
>> 
>>> 59:         Class<?> c = Class.forName("sun.net.www.ParseUtil");
>>> 60:         MH_DECODE = LOOKUP.findStatic(c, "decode", methodType(String.class, String.class));
>>> 61:         MH_TO_URI = LOOKUP.findStatic(c, "toURI", methodType(URI.class, URL.class));
>> 
>> Not sure why `MethodHandles` are used here. Is this to avoid the compile-time dependency on these classes? I believe
>> for better benchmarking `MH_DECODE` and `MH_TO_URI` need to be `static final` to be folded. This would require
>> initializing them in `<clinit>`.
>
> The micros are being awkward to run right now because they are compiled with --enable-preview --release N so this
> precludes using options such as --add-exports that would otherwise be used to compile/run micros for JDK internal
> classes. I could imagine this area being re-visited as there are conflicting needs.

Made `Lookup` and `MethodHandles` static final. @cl4es suggested to use reflection and the Fork annotation to manage
access to the non-exported types in the benchmark, rather than adding the `--add-exports` flag to
`BuildMicrobenchmark.gmk`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/170