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

Reply via email to