RFR: 8159746: (proxy) Support for default methods

[Rémi Forax]

On Wed, 28 Oct 2020 19:28:36 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Hi Mandy and Peter,
>> reading your exchanges, i wonder if it's not better to stop trying to add more and more features to the already clunky java.lang.reflect.Proxy but instead to move to provide the same set of feature but using an implementation based on java.lang.invoke.Lookup/MethodHandle.
>> 
>> I propose to introduce a java.lang.invoke.Proxy has a replacement of java.lang.reflect.Proxy using j.l.i.MethodHandle instead of j.l.r.Method, the equivalent of the InvocationHandler acting as a linker called once per the first time a method of the Proxy is called instead of being called each time a method is called.
>> 
>> Such proxy
>> - has it's security model based on Lookup to define the class,
>>   so no supplementary restrictions on package/module of the interface implemented
>> - avoid to mix java.lang.reflect API and java.invoke API
>> - is transparent in term of exceptions (ther are propagated without any wrapping/unwrapping)
>> - can support default methods natively
>> - doesn't requires any caching (the user will be responsible to do the caching)
>> - is more efficient, actually as efficient as the equivalent written code or a little more (thanks to @ForceInline)
>
> Hi Remi,
> 
> I appreciate your proposal to modernize Proxy API.   There are several requests for this enhancement to support default methods in Proxy.   Defining a new `java.lang.invoke.Proxy` is a much bigger project that I can't tell when the existing users of `java.lang.reflect.Proxy` will be able to get this default method invocation support.  
> 
> I do agree that this API design has many challenges caused by what you listed above.   Well, I believe we are very close to have a consensus:
> 1. New `newProxyInstance` factory method takes a handler factory doing the access check
> 2. Update `getInvocationHandler` to throw `InaccessibleInvocationHandlerException` if access denied to get an invocation handler associated with the proxy instance
> 
> If this needs more time, I think I will consider to shelf this RFE and come back to it later (and consider your proposal as well).

The trick is that if we know that a class like java.lang.invoke.Proxy may exist,
it means that instead of distorting the j.l.r.Proxy API to increase of few percents the performance when calling a default method, you can come with a simpler design in term of API that just add an API point to call a default method.

Better performance becoming on the the goals of java.lang.invoke.Proxy.

-------------

PR: https://git.openjdk.java.net/jdk/pull/313