Yes, I was agreeing with you, Ralph. My (poorly articulated) point was that concatenation can be optimized by the compiler as you mentioned, in addition to cases where not all of the values are known at compile time. Sorry for the confusion!
-ck On Tue, Mar 10, 2020, at 11:13, Ralph Goers 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 > >>>> > >>>> > >>>> > >> > >> > >> > > > > >
