[
https://issues.apache.org/jira/browse/KAFKA-16604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17842016#comment-17842016
]
Chris Egerton commented on KAFKA-16604:
---------------------------------------
I don't know if it's worth the breaking change to disallow manual instantiation
of the {{ConfigKey}} class. If we want to prevent bugs like we saw in
KAFKA-16592, one alternative is to add a builder class for the {{ConfigKey}}
class. This would allow us to add new fields to the {{ConfigKey}} class without
having to add new (public) constructors, or alter existing ones.
> Deprecate ConfigDef.ConfigKey constructor from public APIs
> ----------------------------------------------------------
>
> Key: KAFKA-16604
> URL: https://issues.apache.org/jira/browse/KAFKA-16604
> Project: Kafka
> Issue Type: Improvement
> Reporter: Sagar Rao
> Assignee: Sagar Rao
> Priority: Major
>
> Currently, one can create ConfigKey by either invoking the public constructor
> directly and passing it to a ConfigDef object or by invoking the a bunch of
> define methods. The 2 ways can get confusing at times. Moreover, it could
> lead to errors as was noticed in KAFKA-16592
> We should ideally have only 1 way exposed to the users which IMO should be to
> create the objects only through the exposed define methods. This ticket is
> about marking the public constructor of ConfigKey as Deprecated first and
> then making it private eventually.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
