On 12/21/2012 06:52 PM, Peter Levart wrote:
Hi Henry, again,
To delay constructing message to as late as possible, you could
construct a LogRecord with a reference to Supplier<String> and only
evaluate the Supplier on the first call to LogRecord.getMessage() and
then cache-it. Like the following:
http://dl.dropbox.com/u/101777488/jdk8-tl/LogRecord/webrev/index.html
On a second thought, the above might not be a good idea. The message
should be materialized before passing the LogRecord to a handler, since
some handlers might evaluate message in a special "logging" thread and
therefore invoking a user provided Supplier in another thread might have
undesirable effects (threading issues)...
Regards, Peter
Also, the "staging" Block call-back in doLog() is a very nice lambda
usage, but it comes with a cost of constructing another lambda object
for each call to those methods...
Regards, Peter
On 12/21/2012 07:28 AM, Henry Jen wrote:
Hi,
This patch adds a couple APIs to java.util.logging.Logger so that
construction of log messages only occurs when it is actually to be
logged by using Supplier<String> instead of String.
Since the idea is to avoid unnecessary construction of log messages,
thus APIs imply formatting are not provided. Thus all forms of logrb and
log with Parameters are not included.
log with Throwable are named to be logEx or logpEx to avoid null
ambiguous as it seems like it's quite common usage with
logger.log(level, null, thrown)
Specdiff and webrev can be found at following,
http://cr.openjdk.java.net/~henryjen/ccc/8005263.0/specdiff/diff.html
http://cr.openjdk.java.net/~henryjen/ccc/8005263.0/webrev/
Cheers,
Henry
