[
https://issues.apache.org/jira/browse/KAFKA-12849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17351970#comment-17351970
]
A. Sophie Blee-Goldman commented on KAFKA-12849:
------------------------------------------------
That's something we'll need to consider during the KIP discussion. Just
changing it from a class to an interface is source compatible (though not
binary compatible, which is ok under our policy), however the only thing that
would "break" is if the user was calling the constructor. In KIP-740 we
ultimately decided to deprecate this constructor in 3.0, but we had considered
just changing it directly instead, so I would try to gauge how people feel
about this change. Personally I find it unlikely that anyone was invoking the
constructor, and the constructor itself was not intended to be public, but it
is still possible. So it may be that we need to follow a different approach,
for example by introducing a new interface and just deprecating the entire
class.
We can keep the same name if we just put the interface in the o.a.k.streams
package, which imo makes more sense anyways. Taking this approach would
actually fix one of the messy parts of KIP-740, as we can just start out with a
`public TaskId taskId()` method on the new interface, and remove the `public
TaskId getTaskId()` method on the current TaskMetadata class, which we had to
introduce since the name `taskInfo()` was already taken by a method that just
returned it as a string.
Does all that make sense? Happy to clarify further, but I recommend reading
KIP-740 if you haven't already as it should clear some things up
> Consider migrating TaskMetadata to interface with internal implementation
> -------------------------------------------------------------------------
>
> Key: KAFKA-12849
> URL: https://issues.apache.org/jira/browse/KAFKA-12849
> Project: Kafka
> Issue Type: Improvement
> Components: streams
> Reporter: A. Sophie Blee-Goldman
> Assignee: Josep Prat
> Priority: Major
> Labels: needs-kip, newbie, newbie++
>
> In KIP-740 we had to go through a deprecation cycle in order to change the
> constructor from the original one which accepted the taskId parameter as a
> string, to the new one which takes a TaskId object directly. We had
> considered just changing the signature directly without deprecation as this
> was never intended to be instantiated by users, rather it just acts as a
> pass-through metadata class. Sort of by definition if there is no reason to
> ever instantiate it, this seems to indicate it may be better suited as a
> public interface with the implementation and constructor as internal APIs.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
