andrewfayres commented on issue #12772: [MXNET-984] Add Java NDArray and introduce Java Operator Builder class URL: https://github.com/apache/incubator-mxnet/pull/12772#issuecomment-429250191 I'm not taking a position that Scala objects should never be exposed to Java users. I have no objections to doing so when it's appropriate. My objection is about exposing half a package to them because it is already Java friendly and requiring them to know which parts they are expected to cherry pick from. I think everything you linked to is from outside the core module which I was talking about. The reason I was making that distinction is that it seems to be where they have separate java and scala APIs. At a cursory glance, it looks like the entire mllib module is Java friendly and doesn't have a separate API (like it had been originally designed to be that way). If we'd planned on Java support from the very beginning this is probably how we'd of done things. I have no objections to the idea that we could have them use scala.Tuple2. It's useful, straight forward, is a concept everyone knows, and has no analog in Java SE. I agree that DataDesc is Java-friendly (or at least good enough) but there are plenty of other classes (even in the same IO file as DataDesc) that aren't. I think it's an unreasonable ask to expect the Java Developer to know that they're expected to only select certain things from that package but other things are off limits. I'm not particularly concerned about the maintenance costs because they're just wrappers. The only time I foresee us doing maintenance is if we make a breaking change to the corresponding method of the Scala API which should be very rare (and when it happens there's already so much to update that an extra wrapper should make little difference).
---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected] With regards, Apache Git Services
