Peter, Laurent,
Peter's idea is a good one to add a couple of convenient methods to take
Object parameters that will avoid the creation of array instances. I'd
also like to know what variants being used in the jdk to determine the
pros and cons of the alternatives (this issue also applies to
java.util.logging).
It was intentional to have PlatformLogger define only the useful methods
necessary for jdk use. The goal of PlatformLogger was to provide a
light-weight utility for jdk to log debugging messages and eliminate the
dependency to java.util.logging and avoid the unnecessary j.u.logging
initialization (as disabled by default). It was not a goal for
PlatformLogger to be an exact mirror as java.util.logging.Logger. My
advice is to tune PlatformLogger to provide API that helps the platform
implementation while avoid bloating the API.
Since you are touching some jdk files that use java.util.logging, would
you like to contribute to convert them to use PlatformLogger:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7054233
It's perfectly fine to convert only some of them if not all.
Jim Gish is the owner of logging and will check with him if he has
cycles to work with you on this.
Thanks
Mandy
On 4/8/13 3:06 AM, Laurent Bourgès wrote:
Peter, Mandy,
I think it would be great to make PlatformLogger very similar to
Logger API:
I mean JUL Logger already has only 1 convenient method with 1 param so
it may be great to have the same API in PlatformLogger too: maybe
extend it to 2 or 3 params ...
Peter, could you look at the API differences between Logger /
PlatformLogger to make PlatformLogger API more similar to JUL Logger ?
Laurent
2013/4/8 Peter Levart <peter.lev...@gmail.com
<mailto:peter.lev...@gmail.com>>
On 04/07/2013 07:11 PM, Laurent Bourgès wrote:
Hi
I started fixing All PlatformlLogger "bad" usages and I am fixing
also many jul Logger usages without isLoggable ...
That represents a lot of changes and a very boring job.
I think sending a webrew tomorrow.
Hi Laurent,
Since you're already deep in the task, you might have a rough
feeling what part of such unguarded log statements are of the
following type:
logger.[fine,info,...]("a message with {0} and {1} placeholders",
someArg1, someArg2);
where someArg1, ... are some values that are already present in
the context of the logging statement and don't have to be computed
just for satisfying the logging (not even boxing). Such usages
could be effectively optimized by adding some overloaded methods
to PlatformLogger that take 1, 2, 3, ... arguments:
class PlatformLogger {
...
public void finest(String msg, Object param1) {
if (isLoggable(Level.FINEST)) {
loggerProxy.doLog(Level.FINEST, msg, param1);
}
}
public void finest(String msg, Object param1, Object param2) {
if (isLoggable(Level.FINEST)) {
loggerProxy.doLog(Level.FINEST, msg, param1, param2);
}
}
public void finest(String msg, Object param1, Object param2,
Object param3) {
if (isLoggable(Level.FINEST)) {
loggerProxy.doLog(Level.FINEST, msg, param1, param2,
param3);
}
}
...
This would effectively guard creation of the arguments array with
an isLoggable check for some common usages, eliminating the need
to explicitly guard such statements. Of course, the user would
have to be aware of when such unguarded logging statement is
without overhead and when not...
How do you feel about such API extension?
Regards, Peter
