It would be fun to do a JMH benchmark on String concatenation vs String.join. But yes, that is exactly what I was suggesting.
Ralph > On Mar 11, 2020, at 8:09 AM, Gary Gregory <[email protected]> wrote: > > Java 8 to the rescue somewhat: > > loggerContext.getLogger(String.join(".", MY_ROOT_NAME, "foo", "bar")); > loggerContext.getLogger(String.join(".", MY_ROOT_NAME, "boo", "baz")); > > Gary > > On Tue, Mar 10, 2020 at 4:33 PM Gary Gregory <[email protected]> wrote: > >> On Tue, Mar 10, 2020 at 12:06 PM Ralph Goers <[email protected]> >> wrote: >> >>> >>> >>>> On Mar 10, 2020, at 8:40 AM, Gary Gregory <[email protected]> >>> wrote: >>>> >>>> My POV has nothing to do with performance, more about code clarity. >>>> Building strings 'manually' can be error/typo prone, you can type a ',' >>>> instead of a '.' for example. The idea being using String... was to >>>> formalize the split of hierarchical elements just like you see in APIs >>>> like java.nio.file.Paths.get(String, String…) >>> >>> This would make sense if you were constructing Loggers from their >>> parents, but even that doesn’t make sense since Loggers declared in classes >>> are generally terminal (i.e. - no children). >>> >> >> These are not the usual one-logger-per-Java-class Loggers, these are for >> higher-level abstractions in this app (details are not important but >> involve MapMessage that end up in JDBC and JMS appenders.) >> >> >>> I would argue that if you really want to do this create a utility method >>> that constructs the string and pass that to getLogger() - such as >>> getLogger(nameBuilder(ROOT).append(NEXT).append(FINAL).build()); or >>> something similar. But I would think a name builder like this would have >>> more of a place in Commons Text than here. >>> >> >> I see what you are saying but I am not sure I want to go that route. >> >> I might have to leave it as is since this proposal is presents more >> friction than I thought. >> >> Thank you all for sounding this out. >> >> Gary >> >> >>> Ralph >>> >>> >>> >>> >>>
