Hi Jay, Thanks for the explanation.
My take is that the main benefit in keeping pluggable broker interfaces in Java is that implementors don't have to include the Scala library (and don't have to choose a Scala version, for example). I think this is a strong enough reason on its own. I am less convinced about the compatibility argument, but it doesn't matter. :) The follow-up question is where these classes should live. We have the common package in clients for common code. However, if something is exclusively used by the broker, we could add it under core/src/main/java instead. There are pros and cons for each approach, so I was wondering if some thought has gone into this already. Ismael On Wed, Apr 6, 2016 at 4:58 PM, Jay Kreps <j...@confluent.io> wrote: > Hey Ismael, > > Yeah I think this is a minor cleanliness thing. Since this is kind of a > power user interface I don't feel strongly either way. > > My motivation with Scala is just that we've tried to move to having the > public interfaces be Java, and as a group we definitely struggled a lot > with understanding and maintaining Scala compatibility in the older > clients. > > -Jay > > On Tue, Apr 5, 2016 at 11:46 PM, Ismael Juma <ism...@juma.me.uk> wrote: > > > Hi Jay, > > > > On Wed, Apr 6, 2016 at 3:48 AM, Jay Kreps <j...@confluent.io> wrote: > > > > > Given that we're breaking compatibility anyway should we: > > > > > > > We are not breaking source compatibility since the new method has a > default > > implementation. I take it that you mean binary compatibility? > > > > > > > 1. Remove the get prefix on this method and the existing one which > > violate > > > our own code style guidelines (Oops! Kind of sad we went through the > > whole > > > KIP process and no one even flagged this) > > > > > > > I did flag this during the discussion and Ashish said he would change it > if > > other people felt that it should be changed. > > > > > > > 2. Move the interface out of scala to be a normal Java interface > > > > > > This breaks source compatibility but probably what we should have done > > > originally I suspect. Probably there are few enough implementations of > > this > > > that it is better to just rip the bandaid off. > > > > > > > Can you please explain the motivation? It did come up in previous > > discussions that some things like Operation and ResourceType should be in > > the clients library, but not Authorizer itself. Are we saying that any > > pluggable interface should be in Java so that users can implement it > > without including the Scala library? > > > > Grant, you originally suggested that some things would have to be in the > > Java side as well. Can you please elaborate on this? > > > > Ismael > > >
