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]

There may be some performance implications of this, though I would like to measure it first. A rule of thumb is 90-95% of Android methods that get called do not have corresponding shadow methods. With this change, there will be extra reflection work done for 90-95% of these method calls. Maybe it's fine, since shadows typically don't contain too many methods. But I would like to quantify the impact of this change (I can get an estimate).

[hoisie]

An alternative may be to use the Processor to generate a list of shadow methods that are renamed, and store that info in shadow metadata. That may be tricky with custom shadows, though it may also be doable.

[utzcoz]

I prefer the Processor. I will try it this weekend.

[hoisie]

The idea would be store a map in ShadowInfo that contains information about these renamed methods.

[utzcoz]

@hoisie Do you think we still need ShadowInfo for renamed methods? Looks like getDeclaredMethods is not a big performance issue.

[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.