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 >
