On 2016-08-10 02:02, Mandy Chung wrote:
On Aug 9, 2016, at 8:34 AM, Claes Redestad <claes.redes...@oracle.com> 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.
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.
GenerateJLIClassesPlugin.java
Would be good to make JLIA final.
Done.
http://cr.openjdk.java.net/~redestad/8163373/webrev.02/
/Claes
Otherwise looks okay.
Mandy
