----- Mail original ----- > De: "Johannes Kuhn" <i...@j-kuhn.de> > À: "core-libs-dev" <core-libs-dev@openjdk.java.net> > Envoyé: Lundi 1 Février 2021 15:50:51 > Objet: JDK-6824466 java.lang.reflect.Method should use > java.lang.invoke.MethodHandle
> 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) Hi Johannes, the native accessors doesn't play with loom (a C stack frame in the middle of the Java stack can not be moved) so it doesn't seem to be a good idea to rely on the native accessors for hidden classes. > > - Johannes Rémi
