Framework Ops vs Raw Ops

In Python TensorFlow, there are some OPs defined in the Python Layer, and some defined in the C-api layer. I have been tasked to see how Java TensorFlow might want to handle this.

I have run some experiments with creating a FrameworkOperatorProcessor class in tensorflow-flow-generator and a couple of architectures present themselves. This class is basically a copy of OperatorProcessor with some tweaks.

The approaches seem to dictate generating a new class in tensorflow-framework, that I named FOps for now.

1. The first approach is to have FOps subclass org.tensorflow.op.Ops, that is generated in tensorflow-core-api. However, this leads to potential problems with name clashes with the methods and groups already in Ops. A prime example of this are the NN classes we added for Nn and NnRaw (SoftmaxCrossEntropyWithLogits<T> softmaxCrossEntropyWithLogits() has the same signature in both generated classes.) This option requires changing Ops from a final class to non-final so that it can be inherited.

2. A second approach is to use the delegate pattern, and have FOps hold an internal reference to Ops, and you could call methods on each as required. For example,

FOps ftf = FOps.create(graph);
ftf.math.tensordot(); // framework op
ftf.getOps().math.mul();  // raw op

3. Keep both totally separate from each other. This may potentially allow reuse of the existing OperatorProcessor. It may be more cumbersome to the programmer user.

4. Another option, that I haven't thought of yet.

I welcome thoughts on this.

Start by reading the existing OperatorProcessor in tensorflow-flow-generator and compare it with the proposed FrameworkOperatorProcessor. Review the generated Ops, Nn, and NnRaw classes across tensorflow-core-api and tensorflow-framework. Done means selecting and documenting an approach for exposing framework and raw operations in Java.