Mailing-List: contact dev-help@mxnet.incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@mxnet.incubator.apache.org
MIME-Version: 1.0
In-Reply-To: <CANCAKkUaA3omVasDHE2-BYRufhE5-R2nFYPmjRXJ6BE+73xe3A@mail.gmail.com>
References: <CA+V=WqiByQCi+UG-onOZUpF-7=1d_DTNy+i2KS152jsnWRiFRg@mail.gmail.com>
 <CANCAKkX_S-TKJSHb4SCk_PFYrMe1MPdQX1JB4Bs3whjjxisKGg@mail.gmail.com>
 <CA+V=Wqg2t4TSQ+6EtGiuJVt_T=Rmc9NPiNjc31QbC=KchopfeA@mail.gmail.com> <CANCAKkUaA3omVasDHE2-BYRufhE5-R2nFYPmjRXJ6BE+73xe3A@mail.gmail.com>
From: Nan Zhu <zhunanmcgill@gmail.com>
Date: Wed, 16 Aug 2017 08:30:52 -0700
Message-ID: <CAMtqZeeYyzUDb+V8gHhQuN8HkzgUa-GuhmuXX5OXAtgGCYOPOw@mail.gmail.com>
Subject: Re: Java API for MXNet
To: dev@mxnet.incubator.apache.org
Content-Type: multipart/alternative; boundary="94eb2c1cda22cd96b60556e09450"
archived-at: Wed, 16 Aug 2017 15:30:59 -0000

--94eb2c1cda22cd96b60556e09450
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I agree with Yizhi

My major concern is the duplicate implementations, which are usually one of
the major sources of bugs, especially with two languages which are
naturally interactive (OK, Calling Scala from Java might need some more
efforts). It is just like we provide C++ & C APIs of MxNet in two separated
packages.

About dependency problem, when you say "As far as I see this has the great
disadvantage that the Java API would force Scala as a dependency onto the
java users.", would you please give a concrete example causing critical
issues?

Best,

Nan


On Wed, Aug 16, 2017 at 8:19 AM, YiZhi Liu <javelinjs@gmail.com> wrote:

> Hi,
>
> If we build the Java API from the very beginning, i.e. the JNI part,
> we have to rewrite the codes for training, predict, inferShape, etc.
> It would be too heavy to maintain a totally new front language.
>
> As far as I see, I don't think Scala library dependency would be a big
> problem in most cases, unless we are going to use it in embedded
> devices. Could you illustrate some use-cases where you cannot involve
> Scala dependencies?
>
> 2017-08-16 22:13 GMT+08:00 Joern Kottmann <kottmann@gmail.com>:
> > Hello,
> >
> > the approach which is taken by Spark is described here [1].
> >
> > As far as I see this has the great disadvantage that the Java API
> > would force Scala as a dependency onto the java users.
> > For a library it is always a great advantage if it doesn't have many
> > dependencies, or zero dependencies. In our case it could be quite
> > realistic to have a thin wrapper around the C API without needing any
> > other dependencies (or only dependencies which can't be avoided).
> >
> > The JNI layer could easily be shared between the Java and Scala API.
> > As far as I understand is the JNI layer in the Scala API anyway
> > private and a change to it wouldn't require that the public part of
> > the Scala API is changed.
> >
> > What do you think?
> >
> > J=C3=B6rn
> >
> > [1] https://cwiki.apache.org/confluence/display/SPARK/Java+API+Internal=
s
> >
> > On Wed, Aug 16, 2017 at 3:39 PM, YiZhi Liu <javelinjs@gmail.com> wrote:
> >> Hi Joern,
> >>
> >> I suggest to build Java API as a wrapper of Scala API, re-use most of
> >> the procedures. Referring to the Java API in Apache Spark.
> >>
> >> 2017-08-16 18:21 GMT+08:00 Joern Kottmann <joern@apache.org>:
> >>> Hello all,
> >>>
> >>> I would like to propose the addition of a Java API to MXNet.
> >>>
> >>> There has been some previous work done for the Scala API, and it make=
s
> >>> sense to at least share the JNI layer between the two.
> >>>
> >>> The Java  API probably should be aligned with the Python API (and
> >>> others which exist already) with a few changes to give it a native
> >>> Java feel.
> >>>
> >>> As far as I understand there are multiple people interested to work o=
n
> >>> this and it would be good to maybe come up with a written proposal on
> >>> how things should be.
> >>>
> >>> My motivation is to get a Java API which can be used by Apache OpenNL=
P
> >>> to solve various NLP tasks using Deep Learning based approaches and I
> >>> am also interested to work on MXNet.
> >>>
> >>> J=C3=B6rn
> >>
> >>
> >>
> >> --
> >> Yizhi Liu
> >> DMLC member
> >> Technical Manager
> >> Qihoo 360 Inc, Shanghai, China
>
>
>
> --
> Yizhi Liu
> DMLC member
> Technical Manager
> Qihoo 360 Inc, Shanghai, China
>

--94eb2c1cda22cd96b60556e09450--