<AWT Dev> <Swing Dev> sun.awt.X11 logs still using String + (waste)

[Mandy Chung]

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.levart at gmail.com 
> <mailto:peter.levart at 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
>