Status

Current state: "Under Discussion", "Accepted", "Rejected"

Discussion thread: here [Change the link from the KIP proposal email archive to your own email thread]

JIRA: Please keep the discussion on the mailing list rather than commenting on the wiki (wiki discussions get unwieldy fast).

Motivation

Describe the problems you are trying to solve.

Public Interfaces

Briefly list any new interfaces that will be introduced as part of this proposal or any existing interfaces that will be removed or changed. The purpose of this section is to concisely call out the public contract that will come along with this feature.

A public interface is any change to the following:

• Binary log format

• The network protocol and api behavior

• Any class in the public packages under clientsConfiguration, especially client configuration

  • org/apache/kafka/common/serialization

  • org/apache/kafka/common

  • org/apache/kafka/common/errors

  • org/apache/kafka/clients/producer

  • org/apache/kafka/clients/consumer (eventually, once stable)

• Monitoring

• Command line tools and arguments

• Anything else that will likely break existing users in some way when they upgrade

Proposed Changes

Describe the new thing you want to do in appropriate detail. This may be fairly extensive and have large subsections of its own. Or it may be a few sentences. Use judgement based on the scope of the change.

Compatibility, Deprecation, and Migration Plan

• What impact (if any) will there be on existing users?
• If we are changing behavior how will we phase out the older behavior?
• If we need special migration tools, describe them here.
• When will we remove the existing behavior?

Rejected Alternatives

...

Vote thread: here

JIRA:

Pull request: PR#4033

Released: 1.1.0

Motivation

KafkaFuture.Function and KafkaFuture.BiCosumer are currently public abstract classes with only one abstract method.

This means you cannot use them with a java 8 lambda, as that only works for functional interfaces.

Replacing those classes with interfaces makes them lambda compatible.

Public Interfaces

In the public interface, only org.apache.kafka.common.KafkaFuture has helper classes which can better be expressed as functional interfaces.

Proposed Changes

The KIP introduces a FunctionInterface which defines the new functional interface.  The old Function class is kept for backwards compatibility reasons, but documented to be a candidate for deprecation or removal.  The @Deprecated was not yet added to this class. This was also done for the old signature of the thenApply function (the only public function which was using this Function object).

As the Biconsumer class was not used in the public interface, it was changed from a class to an interface.

To make it easier to work with the KafkaFuture the new public function whenComplete is introduced.  This allows the user of KafkaFuture to execute an action after the future is completed and it matches the signature and the behaviour of CompletableFuture#whenComplete.

/**
 * Returns a new KafkaFuture with the same result or exception as this future, that executes the given action
 * when this future completes.
 *
 * When this future is done, the given action is invoked with the result (or null if none) and the exception
 * (or null if none) of this future as arguments.
 *
 * The returned future is completed when the action returns.
 * The supplied action should not throw an exception. However, if it does, the following rules apply:
 * if this future completed normally but the supplied action throws an exception, then the returned future completes
 * exceptionally with the supplied action's exception.
 * Or, if this future completed exceptionally and the supplied action throws an exception, then the returned future
 * completes exceptionally with this future's exception.
 *
 * The action may be invoked by the thread that calls {@code whenComplete} or it may be invoked by the thread that
 * completes the future.
 *
 * @param action the action to preform
 * @return the new future
 */
public abstract KafkaFuture<T> whenComplete(BiConsumer<? super T, ? super Throwable> action);

Compatibility, Deprecation, and Migration Plan

In a future release the KafkaFuture.Function and thenApply function which uses this class can be marked as @Deprecated.  Later on they can be removed.

When KIP-118 is implemented, KafkaFuture can extend CompletableFuture or implement CompletionStage.

Rejected Alternatives

• Keep the current interface as is, as a nicer syntax to address this api might not be worth breaking backwards compatibility
• Wait for a kafka release which will not support java 7 anymore.  And replace or extend KafkaFuture with the java 8 CompletionStage. This KIP can then become part of KIP-118: Drop Support for Java 7