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...)
Gary On Tue, Mar 10, 2020 at 11:14 AM Ralph Goers <[email protected]> wrote: > Even with that, it is still no match for string concatenation performed by > the compiler. Notice that Gary’s example is concatenating two constants. > The compiler can detect that and concatenate them into a single string > during compilation. > > In any case, using the comma operator means we would have to perform the > concatenation instead of letting the compiler do it. This might make sense > if there was some use case where the concatenation was going to be avoided > like we have in logging calls, but the isn’t the case. > > I just can’t think of a reason why this would be “better”. > > Ralph > > > On Mar 10, 2020, at 7:34 AM, Carter Kozak <[email protected]> wrote: > > > > Jdk9+ provides https://openjdk.java.net/jeps/280 which makes string > concatenation with dynamic values more performant than string builders. > That said, requesting loggers from the context is already relatively > expensive and isn't expected to be on hot paths. > > > > -ck > > > > On Tue, Mar 10, 2020, at 10:32, Ralph Goers wrote: > >> Cleaner? You changed a plus sign to a comma and turned the > concatenation from happening at compile time to runtime. Even if you could > I would argue you shouldn’t. > >> > >> Ralph > >> > >>> On Mar 10, 2020, at 7:10 AM, Gary Gregory <[email protected]> > wrote: > >>> > >>> On Mon, Mar 9, 2020 at 11:10 AM Ralph Goers < > [email protected]> > >>> wrote: > >>> > >>>> Why would you want to do that? Most people seem to prefer getLogger() > >>>> while I prefer getLogger(MyClass.class). I can’t imagine why anyone > would > >>>> want to dynamically construct a name like that and if they did, why > >>>> wouldn’t they just using StringBuilder? > >>>> > >>> > >>> I have a logger name root name in a constant like ROOT_LOGGER_NAME and > >>> right now I create a hierarchy like akin to this: > >>> > >>> loggerContext.getLogger(ROOT_LOGGER_NAME + ".client.request"); > >>> loggerContext.getLogger(ROOT_LOGGER_NAME + ".client.response"); > >>> loggerContext.getLogger(ROOT_LOGGER_NAME + ".server.request"); > >>> loggerContext.getLogger(ROOT_LOGGER_NAME + ".server.response"); > >>> > >>> This could all be clearer if the API was a String... instead of a > String. > >>> > >>> loggerContext.getLogger(ROOT_LOGGER_NAME, CLIENT, REQUEST); > >>> loggerContext.getLogger(ROOT_LOGGER_NAME, CLIENT, RESPONSE); > >>> loggerContext.getLogger(ROOT_LOGGER_NAME, SERVER, REQUEST); > >>> loggerContext.getLogger(ROOT_LOGGER_NAME, SERVER, RESPONSE ); > >>> > >>> Gary > >>> > >>> > >>>> Ralph > >>>> > >>>>> On Mar 9, 2020, at 7:51 AM, Gary Gregory <[email protected]> > wrote: > >>>>> > >>>>> Hi All: > >>>>> > >>>>> Any thought for or against adding the API 'getLogger(String... name)' > >>>> which > >>>>> would build a hierarchical logger name. These would be equivalent: > >>>>> > >>>>> - getLogger("com.a.b.c") > >>>>> - getLogger("com", "a", "b", "c") > >>>>> > >>>>> Gary > >>>> > >>>> > >>>> > >> > >> > >> > > > > >
