Page History

...

With this project, we want to build Java APIs that are easy to use for Inference and lowers the entry barrier is consuming MXNet for production use-cases.

Goals

Proposed Approach

...

1. New Inference Java API
2. Easy to use (idiomatic) - this likely means optimizing for the Java inference use case and not just copying how the python api works
3. Limited dependencies 
4. Full test coverage
5. Performance - Should be at least as performant as the python API

Proposed Approach

Currently there are two approaches being considered/researched:

1. Java wrapper around new Scala API - One approach being considered is using the new Scala API bindings from inside Java. It is already possible to call the Scala bindings from inside Java but the current process would be very painful for users to implement. To improve upon this experience, a Java wrapper would be created to call the Scala bindings. The wrapper could be designed so that it abstracts away the complexities of the Java/Scala interaction and is more idiomatic for the Java inferencing use case. 
   1. Advantages
      1. Interaction with the native code is already done. The implementation and maintenance should be simplified due to this. 
   2. Disadvantages
      
      1. At a minimum this would introduce a dependency upon the Scala compiler.
      2. Interaction with the Scala code could be complicated due to differences in the languages. Known issues are forming Scala collections and leveraging default values. Changes to the Scala API or the introduction of a builder function seems like the most obvious solutions here.
2. Writing a Java API that directly calls the native code - Doing this would be designing and implementing a Java API that will interact with the native code using JNI/JNA. Similar to the other solution, the API would be designed to make Java inferencing simple and idiomatic.
   1. Advantages
      1. No added dependencies
      2. No surprises from interacting with the Scala code
   2. Disadvantages
      1. It is difficult to write and test JNI code.
      2. Possible duplication of efforts between this and the Scala API

Alternative Approaches considered

...