[jira] [Commented] (KAFKA-7435) Consider standardizing the config object pattern on interface/implementation.
[ https://issues.apache.org/jira/browse/KAFKA-7435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17517103#comment-17517103 ] Bruno Cadonna commented on KAFKA-7435: -- Removing from the 3.2.0 release since code freeze has passed. > Consider standardizing the config object pattern on interface/implementation. > - > > Key: KAFKA-7435 > URL: https://issues.apache.org/jira/browse/KAFKA-7435 > Project: Kafka > Issue Type: Improvement > Components: streams >Reporter: John Roesler >Priority: Major > > Currently, the majority of Streams's config objects are structured as a > "external" builder class (with protected state) and an "internal" subclass > exposing getters to the state. This is serviceable, but there is an > alternative we can consider: to use an interface for the external API and the > implementation class for the internal one. > Advantages: > * we could use private state, which improves maintainability > * the setters and getters would all be defined in the same class, improving > readability > * users browsing the public API would be able to look at an interface that > contains less extraneous internal details than the current class > * there is more flexibility in implementation > Alternatives > * instead of external-class/internal-subclass, we could use an external > *final* class with package-protected state and an internal accessor class > (not a subclass, obviously). This would make it impossible for users to try > and create custom subclasses of our config objects, which is generally not > allowed already, but is currently a runtime class cast exception. > Example implementation: [https://github.com/apache/kafka/pull/5677] > This change would break binary, but not source, compatibility, so the > earliest we could consider it is 3.0. > To be clear, I'm *not* saying this *should* be done, just calling for a > discussion. Otherwise, I'd make a KIP. > Thoughts? -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (KAFKA-7435) Consider standardizing the config object pattern on interface/implementation.
[ https://issues.apache.org/jira/browse/KAFKA-7435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17443705#comment-17443705 ] David Jacot commented on KAFKA-7435: Moving to the next release as we are past the 3.1 release code freeze. > Consider standardizing the config object pattern on interface/implementation. > - > > Key: KAFKA-7435 > URL: https://issues.apache.org/jira/browse/KAFKA-7435 > Project: Kafka > Issue Type: Improvement > Components: streams >Reporter: John Roesler >Priority: Major > Fix For: 3.1.0 > > > Currently, the majority of Streams's config objects are structured as a > "external" builder class (with protected state) and an "internal" subclass > exposing getters to the state. This is serviceable, but there is an > alternative we can consider: to use an interface for the external API and the > implementation class for the internal one. > Advantages: > * we could use private state, which improves maintainability > * the setters and getters would all be defined in the same class, improving > readability > * users browsing the public API would be able to look at an interface that > contains less extraneous internal details than the current class > * there is more flexibility in implementation > Alternatives > * instead of external-class/internal-subclass, we could use an external > *final* class with package-protected state and an internal accessor class > (not a subclass, obviously). This would make it impossible for users to try > and create custom subclasses of our config objects, which is generally not > allowed already, but is currently a runtime class cast exception. > Example implementation: [https://github.com/apache/kafka/pull/5677] > This change would break binary, but not source, compatibility, so the > earliest we could consider it is 3.0. > To be clear, I'm *not* saying this *should* be done, just calling for a > discussion. Otherwise, I'd make a KIP. > Thoughts? -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (KAFKA-7435) Consider standardizing the config object pattern on interface/implementation.
[ https://issues.apache.org/jira/browse/KAFKA-7435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17377768#comment-17377768 ] Konstantine Karantasis commented on KAFKA-7435: --- [~vvcephei] [~guozhang] this feature doesn't seem to have made it before feature freeze for 3.0. Postponing to the next release, but let me know if we should do otherwise. > Consider standardizing the config object pattern on interface/implementation. > - > > Key: KAFKA-7435 > URL: https://issues.apache.org/jira/browse/KAFKA-7435 > Project: Kafka > Issue Type: Improvement > Components: streams >Reporter: John Roesler >Priority: Major > Fix For: 3.0.0 > > > Currently, the majority of Streams's config objects are structured as a > "external" builder class (with protected state) and an "internal" subclass > exposing getters to the state. This is serviceable, but there is an > alternative we can consider: to use an interface for the external API and the > implementation class for the internal one. > Advantages: > * we could use private state, which improves maintainability > * the setters and getters would all be defined in the same class, improving > readability > * users browsing the public API would be able to look at an interface that > contains less extraneous internal details than the current class > * there is more flexibility in implementation > Alternatives > * instead of external-class/internal-subclass, we could use an external > *final* class with package-protected state and an internal accessor class > (not a subclass, obviously). This would make it impossible for users to try > and create custom subclasses of our config objects, which is generally not > allowed already, but is currently a runtime class cast exception. > Example implementation: [https://github.com/apache/kafka/pull/5677] > This change would break binary, but not source, compatibility, so the > earliest we could consider it is 3.0. > To be clear, I'm *not* saying this *should* be done, just calling for a > discussion. Otherwise, I'd make a KIP. > Thoughts? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (KAFKA-7435) Consider standardizing the config object pattern on interface/implementation.
[ https://issues.apache.org/jira/browse/KAFKA-7435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16626117#comment-16626117 ] John Roesler commented on KAFKA-7435: - Thanks for the context, [~guozhang]. I agree it would not have been attractive with Java 7 interfaces. Note that the "flexible implementation" argument is actually the justification for Suppressed being an interface in KAFKA-7223 / KIP-328 / [https://github.com/apache/kafka/pull/5567] . That changeset is what got me thinking about applying the pattern more broadly. If we are comfortable using interfaces on an as-needed basis, then we don't need to do anything at all! > Consider standardizing the config object pattern on interface/implementation. > - > > Key: KAFKA-7435 > URL: https://issues.apache.org/jira/browse/KAFKA-7435 > Project: Kafka > Issue Type: Improvement > Components: streams >Reporter: John Roesler >Priority: Major > Fix For: 3.0.0 > > > Currently, the majority of Streams's config objects are structured as a > "external" builder class (with protected state) and an "internal" subclass > exposing getters to the state. This is serviceable, but there is an > alternative we can consider: to use an interface for the external API and the > implementation class for the internal one. > Advantages: > * we could use private state, which improves maintainability > * the setters and getters would all be defined in the same class, improving > readability > * users browsing the public API would be able to look at an interface that > contains less extraneous internal details than the current class > * there is more flexibility in implementation > Alternatives > * instead of external-class/internal-subclass, we could use an external > *final* class with package-protected state and an internal accessor class > (not a subclass, obviously). This would make it impossible for users to try > and create custom subclasses of our config objects, which is generally not > allowed already, but is currently a runtime class cast exception. > Example implementation: [https://github.com/apache/kafka/pull/5677] > This change would break binary, but not source, compatibility, so the > earliest we could consider it is 3.0. > To be clear, I'm *not* saying this *should* be done, just calling for a > discussion. Otherwise, I'd make a KIP. > Thoughts? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (KAFKA-7435) Consider standardizing the config object pattern on interface/implementation.
[ https://issues.apache.org/jira/browse/KAFKA-7435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16626080#comment-16626080 ] Guozhang Wang commented on KAFKA-7435: -- John, thanks for the proposal. We did talk about this approach when introducing the config object for the first time, but since J7 is not dropped at that time which does not support static function on interface we have to ditch this idea. Personally I think it is a good-to-have, but probably not must-have given its compatibility implications comparing the listed advantages. If we encountered some cases where, for example, "flexibility in implementation" is definitely needed maybe we can propose this change then? > Consider standardizing the config object pattern on interface/implementation. > - > > Key: KAFKA-7435 > URL: https://issues.apache.org/jira/browse/KAFKA-7435 > Project: Kafka > Issue Type: Improvement > Components: streams >Reporter: John Roesler >Priority: Major > Fix For: 3.0.0 > > > Currently, the majority of Streams's config objects are structured as a > "external" builder class (with protected state) and an "internal" subclass > exposing getters to the state. This is serviceable, but there is an > alternative we can consider: to use an interface for the external API and the > implementation class for the internal one. > Advantages: > * we could use private state, which improves maintainability > * the setters and getters would all be defined in the same class, improving > readability > * users browsing the public API would be able to look at an interface that > contains less extraneous internal details than the current class > * there is more flexibility in implementation > Alternatives > * instead of external-class/internal-subclass, we could use an external > *final* class with package-protected state and an internal accessor class > (not a subclass, obviously). This would make it impossible for users to try > and create custom subclasses of our config objects, which is generally not > allowed already, but is currently a runtime class cast exception. > Example implementation: [https://github.com/apache/kafka/pull/5677] > This change would break binary, but not source, compatibility, so the > earliest we could consider it is 3.0. > To be clear, I'm *not* saying this *should* be done, just calling for a > discussion. Otherwise, I'd make a KIP. > Thoughts? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
