Support customized implementation method name

[utzcoz]

Sometimes internal methods return different types for different SDKs. It's safe because
these methods are internal/private methods, not public methods. To support different return
types of a method for different SDKs, we often use looseSignature method, although all return
types are common types like bool and int. This field/property can be used to fix this issue by
using different real methods for different SDKs.

[utzcoz]

@hoisie @brettchabot It's a prototype, but it's ready for reviewing now.

[utzcoz]

Friendly ping @hoisie @brettchabot, PTAL.

[hoisie]

@utzcoz it looks like getDeclaredMethod iterates over all methods of a class until it finds the first match, so I think iterating over all the methods should not be a performance issue:

https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/Class.java#L2905

    @CallerSensitive
    public Method getDeclaredMethod(String name, Class<?>... parameterTypes)
        throws NoSuchMethodException, SecurityException {
        Objects.requireNonNull(name);
        @SuppressWarnings("removal")
        SecurityManager sm = System.getSecurityManager();
        if (sm != null) {
            checkMemberAccess(sm, Member.DECLARED, Reflection.getCallerClass(), true);
        }
        Method method = searchMethods(privateGetDeclaredMethods(false), name, parameterTypes);
        if (method == null) {
            throw new NoSuchMethodException(methodToString(name, parameterTypes));
        }
        return getReflectionFactory().copyMethod(method);
    }

This is searchMethods:

   // This method does not copy the returned Method object!
    private static Method searchMethods(Method[] methods,
                                        String name,
                                        Class<?>[] parameterTypes)
    {
        ReflectionFactory fact = getReflectionFactory();
        Method res = null;
        for (Method m : methods) {
            if (m.getName().equals(name)
                && arrayContentsEq(parameterTypes,
                                   fact.getExecutableSharedParameterTypes(m))
                && (res == null
                    || (res.getReturnType() != m.getReturnType()
                        && res.getReturnType().isAssignableFrom(m.getReturnType()))))
                res = m;
        }
        return res;
    }

[hoisie]

Looks like the only difference is that calling getDeclaredMethods calls copyMethods.

  @CallerSensitive
    public Method[] getDeclaredMethods() throws SecurityException {
        @SuppressWarnings("removal")
        SecurityManager sm = System.getSecurityManager();
        if (sm != null) {
            checkMemberAccess(sm, Member.DECLARED, Reflection.getCallerClass(), true);
        }
        return copyMethods(privateGetDeclaredMethods(false));
    }

[utzcoz]

@hoisie If methodName can support regex or we create a new annotation to support method mapping with regex, we can use it to support Kotlin internal property's shadow. It's can expand shadow mechanism for Kotlin and help developers to use Robolectric shadow their custom code(although I know it's not the main purpose of Robolectric's shadow usage scenario).

[utzcoz]

Looks like the only difference is that calling getDeclaredMethods calls copyMethods.

Interesting. I keep to use getDeclaredMethods like your suggested, but create a local variable called methods to only call it once, and multiple iterations use the same methods instance to reduce copy operations.

From my experience, I can't use only one iteration to finish all types of finding jobs, as the exact matching has the first and highest priority than other approaches. So I reused the origin iteration with the exact method matching with highest priority and then looseSignature, and adding a new iteration for methodName with the third priority.

[utzcoz]

@hoisie Friendly ping for reviewing. I want to land it before other contributors start to code for GSoC.

[utzcoz]

@hoisie Maybe we can discuss this one?

[utzcoz]

Friendly ping @hoisie for reviewing.

[utzcoz]

we can use it to support Kotlin internal property's shadow

I think developers can use JvmName to set the generated method signature, especially method name for internal Kotlin property's setter and getter.

[utzcoz]

@hoisie @MGaetan89 Okay, I decide to land it because long-time no-feedback. If you have other questions, please let me know, I can send new PRs to fix them or @Mia0451 can help to improve it under her GSoC project as methodName is very important to remove looseSignature for classes that have same method name + different signatures for different Android SDKs.