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

Peter Levart peter.levart at gmail.com
Thu Dec 27 16:55:52 PST 2012


And to save creation of a helper object, LogRecordFactory could be an 
interface implemented by LogRecord...

Peter

On 12/28/2012 01:42 AM, Peter Levart wrote:
> What about the following API:
>
> public class LogRecordFactory {
>
>     private final Level level;
>
>     public LogRecordFactory(Level level) {
>         this.level = level;
>     }
>
>     public LogRecord create(String msg) {
>         return new LogRecord(level, msg);
>     }
>
>     public LogRecord create(String msg, Object... parameters) {
>         LogRecord lr = create(msg);
>         lr.setParameters(parameters);
>         return lr;
>     }
>
>     // ...etc...
> }
>
>
> and then in the Logger...
>
>     public void log(Level level, Function<LogRecordFactory, LogRecord> 
> logRecordProducer) {
>         if (level.intValue() < levelValue || levelValue == offValue) {
>             return;
>         }
>         LogRecord lr = logRecordProducer.apply(new 
> LogRecordFactory(level));
>         doLog(lr);
>     }
>
>
> which would be used as:
>
>         logger.log(Level.INFO, lrp -> lrp.create("Status is: %s", 
> getStatus()));
>
>
> Regards, Peter
>
>
> On 12/27/2012 01:23 AM, Henry Jen wrote:
>> On 12/22/2012 07:30 AM, Jason Mehrens wrote:
>>> The msg argument in most cases is a string literal because it is either
>>> a resource bundle key or a MessageFormat literal.  The established best
>>> practice is to convert on the fly construction of messages to use
>>> the MessageFormat syle logging.  This current patch is kind of
>>> anti-pattern of that practice.  I would think the real win would be to
>>> delay construction of the 'params' argument in the logging framework.
>>> Allowing the callers to write logger.log(level, "{0}", Foo::bar) and
>>> have the call to bar be lazy eval would be the best of both the logging
>>> world and the lambda world.
>> 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
>>
>



More information about the lambda-dev mailing list