I think a significant fraction of the community would disagree with you.
We ran a survey where we collected suggestions for lambdafying API
methods, and this one came in top of the list.
There is a significant fraction of the developer community that uses the
logging API and doesn't care at all about localization, but does care
about logging performance. One doesn't have to look very far to see
that it is common practice to surround logging calls with
if (logger.isLogging(level))
logger.log(level, msgExpr)
to work around the eager evaluation. And such a practice is brittle,
because it's easy to forget to do it in one place, and lose the benefit.
Now, your answer might be "force all users to use message catalogs."
But that's pretty mean. A lot of users really, really don't want to use
message catalogs. They want to do:
logger.log(level, () -> String.format(...));
You're basically saying we should force-feed those users some
message-catalog vegetables, because it's good for them.
Henry,
Please don't apply this patch. This patch and the suggested workarounds are
still an anti-pattern of the logging API. You don't want to encourage this
type of on the fly message construction because it can't be localized. Even
Netbeans has a code hint to undo this pattern that you are enabling. The
problem with this patch is it fails to meet even its own goals when used it in
a real world context. The stated goal is to eliminate unnecessary message
construction but, in this patch you will pay the cost of message construction
when you create a LogRecord. If you configure a system with MemoryHandler to
track the events that lead up to a failure you will pay the message cost on
every LogRecord that passes through the ring buffer. With this API change, we
are performing costly message construction for evicted and unformatted records
which is awful. This same kind of worst case behavior happens when the handler
levels are higher than the logger level or if a handler is !
using a
filter to track a specific error. I've used combinations of those logging configurations on production applications to track down elusive errors (See bug 6219960). This patch assumes that if a record is loggable by a logger that it will be formatted and that is incorrect. In the 1.4-1.7 logging, message construction cost is delayed until formatting which is as lazy as it gets in the logging world. Take the workaround you suggest bellow. If you apply Object.toString() to any of the arguments, then that cripples what you can do with custom Filter or custom Formatter because you want to be able to access the arguments in their original form and not the string representation. Also, you always want to use the ResouceBundle assigned to the LogRecord from the logger to do the localization. The msg supplier won't know what that is at the time the lambda is created or I would have to recreate code that the logger already does for me every time I want to log something. It would!
be easie
r to do what we've done since 1.4 which is use a guard statement to avoid
evaluation of the expensive method call. Against this patch if I use a lambda
or a guard they will both evaluate the expensive call under the same scenarios.
Take the 'DiagnosisMessages::systemHealthStatus' example from the API docs.
Seems fine until you realize that someday you might have to read the output of
that statement in a log somewhere or you want to create a filter that only
shows when the system is unhealthy. So you start to transform that example and
realize that you don't want to create a 'systemHealthStatusWithContextMsg'
method because it can't be localized during formatting. You don't want to
simply perform msg concatenation because that is bad practice and doesn't use
lambda. So skip using the lambda APIs because you can use the parameterized
logging with a guard statement and that allows you to localize the message and
or use the raw parameter data in a Filter to determine which !
system va
lue has exceed some threshold without resorting to message parsing. Parameters
are always more useful than a preformatted string message. Once you arrive
here, there is no need for a message parameter to be anything other than a
message format pattern or a resource bundle key. Both of those types of
messages are string literals so I don't need a Supplier. I think what would be
more powerful and fitting patch would be to overload all of the Logger.finest,
Logger.finer, Logger.fine, etc. like 'Logger.finer(String msg, Throwable
thrown, Supplier... params)' or use a sub-interface of Supplier. As long as
the given Supplier.toString() is implemented as: 'return String.valueof(get())'
then the existing logging API would format these lazy parameters the same way
and would properly delay the construction cost to only at the time of
formatting. Filters would be allowed access to the original parameters through
the supplier interface and the already established localization in th!
e logging
API would still work. The established best practice of not creating on the fly
messages would still remain an enduring goal of the logging API. Respectfully,
Jason
For messages not just only for developer, they should be localized as
you suggested and in such cases, it is possible to achieve the laziness
via Object.toString(), less straightforward than using a lambda, but is
possible.
Cheers,
Henry
