Re: RFR 2: JDK-8005263: Logging APIs takes Supplier for message

2013-01-02 Thread David M. Lloyd
Being a devil's advocate here, I'd like to point out that the particular example given: >logger.log(level, () -> String.format(...)); is better done through an API like this one: logger.logf(level, fmt, ...); which would in fact allow for the possibility of localization (using the fo

RE: RFR 2: JDK-8005263: Logging APIs takes Supplier for message

2013-01-01 Thread Jason Mehrens
e: RFR 2: JDK-8005263: Logging APIs takes Supplier for message > From: henry@oracle.com > Date: Fri, 28 Dec 2012 16:11:02 -0800 > CC: brian.go...@oracle.com; lambda-...@openjdk.java.net; > core-libs-dev@openjdk.java.net > To: jason_mehr...@hotmail.com > > Jason, > &

Re: RFR 2: JDK-8005263: Logging APIs takes Supplier for message

2012-12-28 Thread Henry Jen
On Dec 28, 2012, at 4:11 PM, Henry Jen wrote: > Next version I'll enable defer message construction until Logger filter check. > On a second thought and after more reading into logging code in JDK, it seems like Filter is mostly applied to Handler instead of Logger, thus it's not really that

Re: RFR 2: JDK-8005263: Logging APIs takes Supplier for message

2012-12-28 Thread Henry Jen
f I created a working proof of concept would that change > anything or is this patch a done deal? > > Jason >> Subject: Re: RFR 2: JDK-8005263: Logging APIs takes Supplier for >> message >> From: henry@oracle.com >> Date: Thu, 27 Dec 2012 18:24:17 -0800 >> CC: b

RE: RFR 2: JDK-8005263: Logging APIs takes Supplier for message

2012-12-28 Thread Jason Mehrens
messages that led up to the error. That was the technique used to reopen bug id 6840067. If I created a working proof of concept would that change anything or is this patch a done deal? Jason > Subject: Re: RFR 2: JDK-8005263: Logging APIs takes Supplier for > message > From: henry@o

Re: RFR 2: JDK-8005263: Logging APIs takes Supplier for message

2012-12-27 Thread Henry Jen
As stated in the beginning of the review thread, the reason we don't have Supplier version for other API is that a formatter is involved and can achieve same laziness easily. The key is MessageFormatter can take arguments, which will be used to generate the output. As there is no directly suppo

Re: RFR 2: JDK-8005263: Logging APIs takes Supplier for message

2012-12-27 Thread Peter Levart
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)

Re: RFR 2: JDK-8005263: Logging APIs takes Supplier for message

2012-12-27 Thread Peter Levart
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(Strin

RE: RFR 2: JDK-8005263: Logging APIs takes Supplier for message

2012-12-27 Thread Jason Mehrens
Brian, It's on my list too for lambdafying I just disagree with current implementation. I understand and agree that having to create a guard should not be required. It's awful to have to do. The point is that patch is still way too eager because you don't want to evaluate a message u

Re: RFR 2: JDK-8005263: Logging APIs takes Supplier for message

2012-12-27 Thread Brian Goetz
I think a significant fraction of the community would disagree with you. We ran a survey where we collected suggestions for lambdafying API methods, and this one came in top of the list. There is a significant fraction of the developer community that uses the logging API and doesn't care at a

RE: RFR 2: JDK-8005263: Logging APIs takes Supplier for message

2012-12-27 Thread Jason Mehrens
Henry, Please don't apply this patch. This patch and the suggested workarounds are still an anti-pattern of the logging API. You don't want to encourage this type of on the fly message construction because it can't be localized. Even Netbeans has a code hint to undo this pattern tha

Re: RFR 2: JDK-8005263: Logging APIs takes Supplier for message

2012-12-26 Thread Henry Jen
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. Thi

RE: RFR 2: JDK-8005263: Logging APIs takes Supplier for message

2012-12-22 Thread Jason Mehrens
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 p

Re: RFR 2: JDK-8005263: Logging APIs takes Supplier for message

2012-12-22 Thread Remi Forax
On 12/22/2012 12:13 PM, Peter Levart wrote: Hi Henry, Plain and simple. yes, I just noticed a few spellings: line 670, 696, 863: "Thus is it" -> "Thus it is" - this one has already been written wrong in the original source, so it just multiplied by copy-paste line 688, 743, 854: "Log

Re: RFR 2: JDK-8005263: Logging APIs takes Supplier for message

2012-12-22 Thread Peter Levart
Hi Henry, Plain and simple. I just noticed a few spellings: line 670, 696, 863: "Thus is it" -> "Thus it is" - this one has already been written wrong in the original source, so it just multiplied by copy-paste line 688, 743, 854: "Log a in-time" -> "Log an in-time" Regards, Peter On 12/