Hi Jason, Thanks for weighing in on this. Here's my take:
- I initially opted for overloading, but this met resistance (most vocally from Jay Kreps). I don't have strong feelings either way (I tend to prefer the current proposal without overloading but would understand the need to add it back). - The feedback I got around me (from an admittedly small population sample) is that most people are thinking of migrating to 0.9.0.0. I would wager that a very large majority of users are running production apps on 0.8 clients and would thus not be impacted. The very recent availability of the client libs would also indicate that those having already switched to 0.9.0.0 client libs have a capacity to iterate fast. Jason Gustafson writes: > Hi Pierre, > > Thanks for your persistence on this issue. I've gone back and forth on this > a few times. The current API can definitely be annoying in some cases, but > breaking compatibility still sucks. We do have the @Unstable annotation on > the API, but it's unclear what exactly it means and I'm guessing most users > haven't even noticed it. In the end, I feel we should try harder to keep > compatibility even if it means keeping some of the annoying usage. As an > alternative, maybe we could do the following: > > 1. For subscribe() and assign(), change the parameter type to collection as > planned in the KIP. This is at least source-compatible, so as long as users > compile against the updated release, there shouldn't be any problems. > > 2. Instead of changing the signatures of the current pause/resume/seek > APIs, maybe we can overload them. This keeps compatibility and supports the > more convenient collection usage, but the cost is some API bloat. > > In my opinion, the slightly increased surface area from overloading is > worth the cost of keeping compatibility. Overloading is very common in Java > APIs, so there's no potential for confusion, and it has basically no > maintenance overhead. However, I know others already expressed opposition > to this, so if it's not agreeable, then I'm probably more inclined to keep > the current API. That said, it's not a strong preference. If the consensus > is to allow the breakage now, it doesn't seem like too big of a deal for > users to update their code. It might be early enough that most users > haven't finished (or perhaps haven't even started) migrating their code to > use the new consumer. > > What do you think? > > Thanks, > Jason > > > On Tue, Jan 26, 2016 at 11:52 AM, Pierre-Yves Ritschard <p...@spootnik.org> > wrote: > >> >> I updated the KIP accordingly. >> >> Cheers, >> - pyr >>
