I see some code verbosity / maintenance problems in a couple similar classes, and seek input from the community on what might be done about it.
NodeConfig & CloudConfig together contain a great deal of node level settings. They are built using the same pattern -- the mentioned class, which is immutable, and a separate builder as an inner class. The immutability & separate builder leads to a *lot* of duplication of each setting. I spot-checked a couple settings and found that each had around 8-9 separate lines of code mentioning the setting in question in the source file! Spread all over the place in the file, of course. I did not count ancillary lines per setting (braces and blank lines). Interestingly, CloudConfig was simple enough that IntelliJ was able to offer to convert it into a Java record for me. I did that and examined the results (with an additional manual intervention of constructor simplification). get'ers were removed and instead replaced with implicitly defined equivalent methods that don't have the "get" prefix, which means all consumers of the methods were updated accordingly. Not sure if this is better but it did cut down on lines of code. I suppose 3 lines per setting were removed, so this is maybe a 33% improvement in LOC. However, the builder still remained, contributing substantially to the line count, and the builder can't be converted as it's mutable. In the end, I'm not sure a configuration class *feels* like a suitable use of a Java record anyway. But maybe it's fine; I don't have a strong opinion. I'm happy to share a draft PR of this experiment. I have to admit, despite the benefits of immutability, the pairing with a mutable builder doesn't seem to warrant the annoyance factor in all the lines of code it takes to maintain it. In other words, it's tempting to imagine the builder by itself being the only thing needed. Maybe with a "finished" boolean state to prevent mutability afterwards. Maybe we need a new vision of these classes which embraces EnvUtils. Nowadays I prefer to avoid the verbosity mess of NodeConfig and instead use EnvUtils (sourced from env & sys props) at the point of need. Thus no 8+ lines to add in NodeConfig. ~ David Smiley Apache Lucene/Solr Search Developer http://www.linkedin.com/in/davidwsmiley
