> On Aug 10, 2016, at 7:17 AM, Claes Redestad <[email protected]> wrote: > > > > On 2016-08-10 02:02, Mandy Chung wrote: >>> On Aug 9, 2016, at 8:34 AM, Claes Redestad <[email protected]> >>> wrote: >>> >>> Hi, >>> >>> please review this patch to replace reflection calls into java.lang.invoke >>> from GenerateJLIClassesPlugin with an internal API exported to jdk.jlink >>> via JavaLangInvokeAccess/SharedSecrets. >>> >>> Webrev: http://cr.openjdk.java.net/~redestad/8163373/webrev.01/ >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8163373 >> MemberName.java >> Since JavaLangInvokeAccess is now extended for other purpose, MemberName >> doesn’t seem the most appropriate place to set JavaLangInvokeAccess. Maybe >> Vladimir or other can recommend another class to setJavaLangInvokeAccess. >> If it stays in MemberName, can you move line 1156-1157 to >> JavaLangInvokeAccess interface. > > Per suggestion from Vladimir I've moved the JLIA definition to > MethodHandleImpl. >
That’s a good place to set JLIA. >> >> GenerateJLIClassesHelper >> I actually think it’s better to keep the generate* methods in >> BoundMethodHandle and DirectMethodHandle is better, closer to the relevant >> context/impl. This helper class doesn’t seem necessary. > > Vladimir asked me to do it like this, since isolating as much as possible of > the logic pertaining to the plugin better allows us to keep the concerns > separate and reduce distracting alternative code paths in core j.l.invoke > code that is not relevant to normal execution. > OK. >> >> GenerateJLIClassesPlugin.java >> Would be good to make JLIA final. > > Done. > > http://cr.openjdk.java.net/~redestad/8163373/webrev.02/ Looks fine to me. Mandy
