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

[Henry Jen]

And deal with serialization is also another concern. As I don't think *ALL* handlers use a different log level to Logger would be that a common case, current implementation should be effective.

This patch is a really simple idea, and as Peter and Remi both have pointed out, there is an associated cost of lambda form. What to expect here is a reasonable saving by replace message construction cost with lambda construction cost.

The block form is really an attempt to not repeating the code everywhere, but the efficient concern is real, so we should probably just copy&paste instead of use block.

The renaming idea is a good one. The original thought is to keep the API arguments in place. Now that Peter proposed, it's definitely looks better and apparently is acceptable to developers.

Cheers,
Henry

On Dec 21, 2012, at 1:37 PM, Peter Levart <peter.levart at gmail.com> wrote:

> 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
>>> 
>> 
>