JDK-6824466 java.lang.reflect.Method should use java.lang.invoke.MethodHandle

Johannes Kuhn info at j-kuhn.de
Mon Feb 1 14:50:51 UTC 2021


While implementing a prototype for JDK-8242888 (Convert dynamic proxy to 
hidden classes) I came across the problem that hidden classes can't be 
mentioned in the constant pool, breaking the constructor for serialization.

To remedy that problem, I used a MHConstructorAccessor which delegates 
the actual work to MethodHandles - not unlike what JDK-6824466 suggests.

As there has been previous work in that area, (I am aware of at least 3 
independently developed prototypes for that bug/enchantment) I would 
like to ask a few questions around it:



1) What are the challenges?

 From the bug I could infer, that it's cold start is slower than 
NativeMethodAccessor, but still faster than the generated (bytecode 
spinning) accessors.

2) Are there any roadblocks that prevent replacing the 
MethodAccessorGenerator with accessors that use MethodHandles?

 From my limited tests, it appears to work well enough.

3) Should I try to implement it?



 From my POV, replacing MethodAccessorGenerator with accessors that 
delegate to MethodHandles has a few benefits:

* Support for hidden classes. (Currently fallback to native accessors)
* Removal of MethodAccessorGenerator (which is old and clunky)

- Johannes


More information about the core-libs-dev mailing list