ableegoldman commented on code in PR #14681:
URL: https://github.com/apache/kafka/pull/14681#discussion_r1379493839
##########
clients/src/main/java/org/apache/kafka/clients/producer/ProducerConfig.java:
##########
@@ -618,7 +618,7 @@ public ProducerConfig(Map<String, Object> props) {
super(CONFIG, props);
}
- ProducerConfig(Map<?, ?> props, boolean doLog) {
+ protected ProducerConfig(Map<?, ?> props, boolean doLog) {
Review Comment:
Interesting, I hadn't heard this definition...I suppose it makes sense in
general, but I would actually argue that this specific scenario demonstrates an
edge case where that definition breaks down. Wouldn't this also mean that we
cannot even add new private constructors to a public class, just because they
would show up in the javadocs? That doesn't sound right...I can see how one
could argue that package-private and protected methods are considered part of
the public API and should not be changed in a backwards incompatible way. But
private methods have javadocs that would change, yet they are definitely not
part of the public API.
(Just curious about this, since I've often wondered if we even have a
specific policy definitely what is/isn't strictly speaking considered a public
API.)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: jira-unsubscr...@kafka.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
