...
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
...
Jira | ||||||||
---|---|---|---|---|---|---|---|---|
|
Motivation
KafkaFuture.Function
and KafkaFuture.BiCosumer
are currently empty public abstract classes with one abstract method.
This means you cannot implement them with a java 8 lambda, as that only works for functional interfaces.
Public Interfaces
From the public interfcate, only org.apache.kafka.common.KafkaFuture
has such helper classes.
Proposed Changes
The current proposal implemented in PR#4033 makes from those abstract classes interfaces.
This is a binary incompatible change. Which might be acceptable as KafkaFuture
is annotated as InterfaceStability.Evolving
, where compatibility may be broken at minor release.
This change also helps to move KafkaFuture
closer to the interface of a java 8 CompletableFuture. As KafkaFuture
's javadoc states:
This will eventually become a thin shim on top of Java 8's CompletableFuture.
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
...
When the change is implemented like proposed, everybody using this api will need to implement instead of extend their implementations of KafkaFuture.Function
and KafkaFuture.Biconsumer
.
Other 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. A backwards incompatible change can then be done to replace
KafkaFuture
withCompletableFuture
- Spend more effort and update the definition of
KafkaFuture
in such a way that it gradually switches toCompletableFuture
. By following an approach which looks like this:- Create new interface versions of
KafkaFuture.Function
andKafkaFuture.BiConsumer
, create new methods which handle those functional interface and preferably line their names up with those ofCompletableFuture
. So for exampleKafkaFuture.addWaiter(BiConsumer)
becomesKafkaFuture.whenComplete(BiConsumerInterface)
. Mark the old methods as@Deprecated
. - When kafka does not support java 7 anymore, let
KafkaFuture
extendCompletableFuture
(or evenCompletionStage
) - Later on the deprecated methods can be removed, and
KafkaFuture
becomes a shim onCompletablefuture
orCompletionStage
.
- Create new interface versions of