[
https://issues.apache.org/jira/browse/KAFKA-6174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16239730#comment-16239730
]
Dong Lin commented on KAFKA-6174:
---------------------------------
[~ijuma] I am still now sure why this change breaks binary compatibility. Even
though we moved `DescribeClusterOptions timeoutMs(Integer timeoutMs)` from
DescribeClusterOptions to AbstractOptions, the compiled jar should include a
method with the same signature in the class DescribeClusterOptions.
https://wiki.eclipse.org/Evolving_Java-based_APIs_2 suggests that it should be
binary compatible to move a API method up type hierarchy. By your knowledge if
binary compatibility, do you think this change in the source code will actually
break binary compatibility?
Even if it breaks binary compatibility, if we were to fix binary compatibility,
we will have to add the method `timeoutMs(Integer timeoutMs)` in all existing
option classes, not just for 1.0, but for all future Kafka versions. I am not
sure we should do this. Do you know our current policy regarding enforcement of
binary compatibility, e.g. is it necessary even if we bump up the major version?
Also, do you know how to reproduce this issue?
> Investigate binary incompatibility issued in DescribeClusterOptions between
> 0.11 and 1.0
> ----------------------------------------------------------------------------------------
>
> Key: KAFKA-6174
> URL: https://issues.apache.org/jira/browse/KAFKA-6174
> Project: Kafka
> Issue Type: Bug
> Reporter: Dong Lin
> Assignee: Dong Lin
>
> From 0.11 to 1.0, we moved `DescribeClusterOptions timeoutMs(Integer
> timeoutMs)` from DescribeClusterOptions to AbstractOptions. User reports that
> code compiled against 0.11.0 fails when it is executed with 1.0 kafka-clients
> jar.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
