RFR 2: JDK-8005263: Logging APIs takes Supplier for message (original) (raw)
Jason Mehrens jason_mehrens at hotmail.com
Tue Jan 1 23:38:15 UTC 2013
- Previous message: Scaling problem of HashMap (introduced with alternative hashing)
- Next message: RFR 2: JDK-8005263: Logging APIs takes Supplier for message
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Henry, For point 1 yes. Not just me, even NetBeans considers it an anti-pattern. Supplier return values should be placed in the LogRecord.setParameters method. The 'msg' argument, if present, should always be string. Using the patch I just described, it would allow callers to write the same code as in your testcase and see the same formatted output. All of the existing features of the logging framework would be usable out of the box should the caller choose to opt in and used them. Under the current patch there is no way to opt in because it only encourages the anti-pattern. All parties involved benefit if we switch this around. I could create a prototype from your patch if need be. For point 2, it is way off track and is not the point I was trying to make. The short answer is that point 1 could be evolved even further. Respectfully, Jason> Subject: Re: RFR 2: JDK-8005263: Logging APIs takes Supplier for message
From: henry.jen at oracle.com Date: Fri, 28 Dec 2012 16:11:02 -0800 CC: brian.goetz at oracle.com; lambda-dev at openjdk.java.net; core-libs-dev at openjdk.java.net To: jasonmehrens at hotmail.com
Jason, If I understand you correctly, there are two main concerns, 1. You want to encourage MessageFormat style logging, consider the other way is an anti-pattern. 2. The construction of message could be further eliminated when a filter is involved.
- Previous message: Scaling problem of HashMap (introduced with alternative hashing)
- Next message: RFR 2: JDK-8005263: Logging APIs takes Supplier for message
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]