mxnet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Qing Lan <>
Subject Re: Feedback request for new Java API
Date Fri, 28 Sep 2018 00:22:12 GMT
I would like to loop this back a layer. Current, there is a discussion in the MXNet Scala community
on the ways to implement the Java APIs. Currently there are two thoughts:

1. Make Scala Java Friendly (Create Java compatible methods in the Scala Class. such as NDArray
with Java compatible constructor)
2. Make Java friendly wrappers in Scala (Andrew's explanation below)

The first approach require minimum input from our side to implement however bring user a bunch
of useless api they may not want to use. It also makes Scala package heavier. The good thing
is these two packages require minimum maintenance cost. As a tradeoff, if any time in the
future we want to make Java big (make Java as the primary language supported by MXNet), then
the migration from Scala to Java will be harmful. Spark consider this carefully and decide
not to change much on their Scala code base to make it more Java.

The second approach will make unique NDArray, Shape, Context and more. The good thing about
this is we can always holds a version control on Java. Some breaking changes on Scala may
not influence much on Java. It did the best way to decouple the module and good for us to
build unique pipeline for Java. The bad thing with this design is the maintenance cost as
we need to keep two code bases, but it also make Java side easy to change to make it better
compatible with users.


´╗┐On 9/27/18, 3:25 PM, "Andrew Ayres" <> wrote:

    Currently, we're working to implement a new Java API and would like some
    feedback from the community on an implementation detail. In short, the new
    Java API will use the existing Scala API (in a manner similar to how the
    current Clojure API works). This basically means that we're making Java
    friendly wrappers to call the existing Scala API.
    The feedback we're looking for is on the implementation of NDArray. Scala's
    NDArray has a significant amount of code which is generated via macros and
    we've got two viable paths to move forward:
    1.) Change the macro to generate Java friendly methods  - To do this we'll
    modify the macro so that the generated methods won't have default/optional
    arguments. There may also have to be some changes to parameter types to
    make them Java friendly. The big advantage here is that ongoing maintenance
    will easier. The disadvantages are that we'll be changing the existing
    Scala NDArray Infer API (it's marked experimental) and Scala users will
    lose the ability to use the default and optional arguments.
    2.) Leave the existing macro in place and add another which generates a
    Java friendly version - The biggest issue here is that we'll be doubling
    the number of macros that we've got to maintain. It'll become even more
    overhead once we start expanding the Java API with more classes that use
    generated code like this. The advantages are that the existing Scala
    NDArray Infer API would remain unchanged for Scala users and that the new
    macro could be optimized to give the best possible experience to the Java

View raw message