RFR: 8163373: Rewrite GenerateJLIClassesPlugin to avoid reflective calls into java.lang.invoke

Mandy Chung mandy.chung at oracle.com
Wed Aug 10 16:16:07 UTC 2016


> On Aug 10, 2016, at 7:17 AM, Claes Redestad <claes.redestad at oracle.com> wrote:
> 
> 
> 
> On 2016-08-10 02:02, Mandy Chung wrote:
>>> On Aug 9, 2016, at 8:34 AM, Claes Redestad <claes.redestad at 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.
> 

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



More information about the core-libs-dev mailing list