BackgroundFunctionExecutor.java failes to detect type when sub-classed

从 BackgroundFunctionExecutor.java 第 140 行开始，检查 backgroundFunctionTypeArgument。复现 issue 中描述的 MyExtendedBackgroundFunction 和 MyFunctionHandler 层次结构，然后验证 executor 能检测到 MyReturnType，同时保留对直接实现的 BackgroundFunction 类型的行为。

Error Condition

Exception in thread "main" java.lang.RuntimeException: Could not determine the payload type for BackgroundFunction of type com.example.MyFunctionHandler; must implement BackgroundFunction for some T at com.google.cloud.functions.invoker.BackgroundFunctionExecutor.forClass(BackgroundFunctionExecutor.java:140) at com.google.cloud.functions.invoker.BackgroundFunctionExecutor.forClass(BackgroundFunctionExecutor.java:113) at com.google.cloud.functions.invoker.runner.Invoker.startServer(Invoker.java:256) at com.google.cloud.functions.invoker.runner.Invoker.main(Invoker.java:127)

Occurs when BackgroundFunction<T> is subclassed:

public abstract class MyExtendedBackgroundFunction<T> implements BackgroundFunction<T>

and

public class MyFunctionHandler extends MyExtendedBackgroundFunction<MyReturnType>

In the class mentioned, the following function fails to detect sub-classed BackgroundFunction type:

static Optional<Type> backgroundFunctionTypeArgument(Class<? extends BackgroundFunction<?>> functionClass) {    
// If this is BackgroundFunction<Foo> then the user must have implemented a method    
// accept(Foo, Context), so we look for that method and return the type of its first argument.    
// We must be careful because the compiler will also have added a synthetic method    
// accept(Object, Context).    
return Arrays.stream(functionClass.getMethods())        
.filter(m -> m.getName().equals("accept") &amp;&amp; m.getParameterCount() == 2            && m.getParameterTypes()[1] == Context.class            &amp;&amp; m.getParameterTypes()[0] != Object.class)        
.map(m -> m.getGenericParameterTypes()[0])        
.findFirst();  
}

This fails for described MyFunctionHandler.

The intent is to add common boilerplate handling for a couple of functions which is common to all. A separate abstract function is employed, but the function fails to load because the type is not determined.

Temporary workaround is to re-implement accept() with the type in the sub-classed object with the type, but is inelegant.