kafka-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ismael Juma <ism...@juma.me.uk>
Subject Re: [DISCUSS] KIP-79 - ListOffsetRequest v1 and offsetForTime() method in new consumer.
Date Sat, 10 Sep 2016 08:01:36 GMT
Becket, comments inline.

On Fri, Sep 9, 2016 at 6:55 PM, Becket Qin <becket.qin@gmail.com> wrote:

> Completely agree that we should have a consistent representation of
> something missing/unknown in the code.
> My understanding of the convention is that -1 means "not
> available"/"unknown". For example, when producer request failed, the offset
> we used in the callback is -1. And Message.NoTimestamp is also -1.

ProducerRecord uses a nullable timestamp instead of Record.NO_TIMESTAMP to
indicate a missing value though. That was the example in my original

Using -1
> instead of null has at least two benefits.
> 1) it works for primitive type as well as classes.

This isn't a benefit outside of very specific use-cases (were the cost of
boxing is a problem). The wrapper classes can be used, after all. The
downsides of using -1 is that the type system doesn't help you (there's a
reason why they're called magic values). If you see a `java.lang.Long`, you
have a hint that `null` is a valid value. The other problem with a -1 for a
timestamp is that you may do nonsensical comparisons against it without
error. When using `null`, it will fail-fast with a NPE so that you can fix
it (even better would be to get compile-time errors, but let's leave that
out of this discussion for now).

> 2) it is easy to send via wire protocols

I think it's important to distinguish what we do in the wire protocols
(which may be more low-level) with what we do in user facing APIs (where
usability and safety are very important).


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message