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