Personally, I like the idea of builders for the producer/consumer themselves, but I'm less enthusiastic about one for ProducerRecord. Mostly because I think the following is overly verbose/reads poorly:
producer.send(ProducerRecord.builder() .topic("mytopic") .key("Key") .value("the-val") .headers(myHeaderIterable) .build()); as compared to: producer.send(new ProducerRecord("mytopic", "Key", "the-val", myHeaderIterable)); I think constructor overloads are fine for small data classes like this. The producer/consumer clietns themselves have a lot of options represented by various configuration keys, and a builder pattern makes these easily discoverable in code. -Tommy On Wed, 2018-07-04 at 15:42 +0200, Matthias Wessendorf wrote: Hi, I was filing KAFKA-7059 ([1]) and sent a PR adding a new ctor: -- public ProducerRecord(String topic, K key, V value, Iterable<Header> headers) --- One reasonable comment on the PR was instead of doing constructor overloading, why not working on a builder for the ProducerRecord class. I think this is generally a nice idea I was wondering if there is much interest in ? Sample: --- final ProducerRecord<String, String> myRecord = ProducerRecord.builder() // or an exposed builder .topic("mytopic") .key("Key") .value("the-val") .headers(myHeaderIterable) .build(); --- While at it - instead of just offering a builder for the "ProducerRecord" class, why not adding a builder for the "KafkaProducer" and "KafkaConsumer" clazzes. --- final KafkaProducer<String, String> myProducer = KafkaProducer.builder() // or an exposed builder clazz .config(myProducerConfig) .keySerializer(myStringSerializer) .valueSerializer(myStringSerializer) .build(); --- to even make the above more nice, I think the "ProducerConfig" (analog the ConsumerConfig) configuration options could be also made accesible w/ this fluent API - instead of properties/map, which is what now dominates the creation of the Consumers/Producers. Any thoughts? If there is interest, I am happy to start a KIP w/ a first draft of the suggested API! Cheers, Matthias [1] https://issues.apache.org/jira/browse/KAFKA-7059 ________________________________ This email and any attachments may contain confidential and privileged material for the sole use of the intended recipient. Any review, copying, or distribution of this email (or any attachments) by others is prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete this email and any attachments. No employee or agent of TiVo Inc. is authorized to conclude any binding agreement on behalf of TiVo Inc. by email. Binding agreements with TiVo Inc. may only be made by a signed written agreement.