[
https://issues.apache.org/jira/browse/KAFKA-2702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14986371#comment-14986371
]
Grant Henke commented on KAFKA-2702:
------------------------------------
[~ijuma] I agree. This would be fairly simple in Scala, as Option is a commonly
used concept and transparently handles null/empty-string/empty-list well.
However, In java its not so common. There are going to be a lot of null
defaults with this change (Its not new, it just was less obvious before with
the required parameter) and thats not great either.
A default of null is not currently allowed. See ConfigDefTest.testNullDefault.
At first look that seams like the best approach. Especially to avoid NPEs. But
without null or some sort of Option type, how do I represent a default of
"unset" for types like Integer or Long? I suspect this is why required was
added. Should I allow null defaults with this change?
> ConfigDef toHtmlTable() sorts in a way that is a bit confusing
> --------------------------------------------------------------
>
> Key: KAFKA-2702
> URL: https://issues.apache.org/jira/browse/KAFKA-2702
> Project: Kafka
> Issue Type: Bug
> Reporter: Gwen Shapira
> Assignee: Grant Henke
> Attachments: ConsumerConfig-After.html, ConsumerConfig-Before.html
>
>
> Because we put everything without default first (without prioritizing),
> critical parameters get placed below low priority ones when they both have
> no defaults. Some parameters are without default and optional (SASL server in
> ConsumerConfig for instance).
> Try printing ConsumerConfig parameters and see the mandatory group.id show up
> as #15.
> I suggest sorting the no-default parameters by priority as well, or perhaps
> adding a "REQUIRED" category that gets printed first no matter what.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
