RFR: JDK-8005263: Logging APIs takes Supplier<String> for message

Peter Levart peter.levart at gmail.com
Fri Dec 21 13:37:05 PST 2012


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
>



More information about the lambda-dev mailing list