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 >
