On Sat, Nov 26, 2016 at 11:08 PM, radai <radai.rosenbl...@gmail.com> wrote:
> "compatibility guarantees that are expected by people who subclass these > classes" > > sorry if this is not the best thread for this discussion, but I just wanted > to pop in and say that since any subclassing of these will obviously not be > done within the kafka codebase - what guarantees are needed? > I elaborated a little in my other message in this thread. A simple and somewhat contrived example: `ConsumerRecord.toString` calls the `topic` method. Someone overrides the `topic` method and it all works as expected. In a subsequent release, we change `toString` to use the field directly (like it's done for other fields like `key` and `value`) and it will break `toString` for this user. One may wonder: why would one override a method like `topic`? That is a good question, but part of the exercise is deciding how we approach these issues. We could make the methods final and eliminate the possibility, we could document it so that users can choose to do weird things if they want, etc. Another thing that is usually good to think about is the expectation for `equals` and `hashCode`. What if subclasses implement them to have value semantics instead of identity semantics. Is that OK or would it break things? Designing for implementation inheritance is generally complex although for simple "record" like classes, it can be easier by following a few guidelines. Ismael
