AbstractGlobalCombineFn hierarchy is inconsistent

[kennknowles]

Subclasses of AbstractGlobalCombineFn seem to be arranged in a way that prevents them from being used with the DataflowRunner. 

Subclasses of AbstractGlobalCombineFn are under either CombineFn or CombineFnWithContext, which seems to be in itself a CombineFn which has access to PipelineOptions and Side Inputs.

However, the DataflowRunner casts all combiners passed from user code to CombineFn (see [1]) which prevents combiners that extend CombineFnWithContext from being used there. 

 

For example: 
public class CustomCombinerFn extends CombineWithContext.CombineFnWithContext<...> {...}
 
final PCollectionView<SomeObject<String>> newCollection = oldCollection
  .apply("Custom Combiner", Combine.globally(new CustomCombinerFn(filter)) 
  .withSideInputs(filter)
  .withoutDefaults()
  .asSingletonView());
 
IMHO either CombineFnWithContext should be a subclass of CombineFn or DataflowRunner should cast the combiner to AbstractGlobalCombineFn. 
 
[1] 

beam/runners/google-cloud-dataflow-java/src/main/java/org/apache/beam/runners/dataflow/DataflowRunner.java

Line 514 in b83b302

(CombineFn) combineTransform.getCombineFn(),

Imported from Jira BEAM-6511. Original Jira may contain additional context.
Reported by: nlofeudo.

[ppawel]

It's the same problem in Dataflow when trying to use CombineFnWithContext with Combine.perKey...

[kennknowles]

Since default methods have been added to interfaces we know longer should rely on abstract classes here. Perhaps there is a way to add an interface that they all implement, removing all the hierarchy nonsense.