Definitely no plans in 0.8, we are trying to get it out the door so we really want to change as little as possible.
We haven't had huge discussions around 0.9 yet, but some of us have had an interest in simplifying the client implementation. To me this would mean (1) move the consumer co-ordination to the broker so it is accessible in all languages, (2) move to non-blocking I/O for the clients, and (3) refine the producer and consumer apis (not the protocol, the interfaces). Taken together these represent a rewrite of the scala clients. It would be possible to go all-in and just do them in Java at the same time. I agree that the client code would ideally be in java and have no dependencies, though I don't know if that is worth the cost. There are a couple minor benefits to Java clients: clearer stack traces, smaller jar file, fewer dependencies, and (ironically) better compatibility with other scala versions. I don't see these as big wins. The big win of this would actually be a clean room java implementation with zero dependencies back or forth to the server. Ideally in a separate repository. This and being in another language would force us to think as the client as fundamentally different from the server. This has mentally been very difficult for the team, for whatever reason, in a shared code base. Having a completely stand alone client would force this issue. I have to say I don't see huge value in trying to split the existing scala code into multiple project directories and jars. Trying to split the existing code would likely just make a mess, as we have tried to share as much code as possible to avoid duplication--so things like message set definition, network code, and utilities are all shared. The cost of a clean-room implementation would be large amounts of code duplication, and a much more jaring experience for us developers. In general programming in Java kind of sucks, and maintaining similar code across two languages would be a real headache. -Jay On Fri, Dec 14, 2012 at 7:57 PM, David Arthur <mum...@gmail.com> wrote: > Seems to be a commonly discussed topic. What do people thing about this? > Are there any plans for it in 0.8? > > When I've done stuff like this in the past for projects, it's been a > combination of reorganizing code and configuring a build tool like Ivy > using sub-modules. Does sbt support modules in a similar fashion? > > The counter argument, of course, is that Kafka is a small project with > minimal dependencies, so a thin client artifact is not going to save you > much. That said, a Java consumer/producer jar with no dependencies would be > nice :) > > -David >
