[slf4j-dev] Boxing costs for primitive types

[Ceki Gülcü]

At 07:55 AM 8/4/2005, you wrote:
>It would seem fairly common to want to do something like:
>
>for (int i = 0; i < 100; i++) {
>    logger.debug("Iteration {}", i);
>}
>
>However, I believe the current SLF4J would incur an boxing cost to
>create an Integer object on each iteration regardless of whether the
>message would be dispatched and would require an explicit new Integer (i) 
>prior to JDK 1.5.
>
>Any thoughts on adding methods like:
>
>void debug(String pattern, int arg1);
>void debug(String pattern, double arg1);
>void debug(String pattern, boolean arg1);


Supporting int, double, boolean, float, long, short, etc would add
another 48 (6 x 4 x 2) methods to the list. If you take two arg
combinations, the number jumps to 336.

As you mention, with the help of the autoboxing feature in JDK 1.5,
one can write

  if(logger.isDebugEnabled()) {
    for (int i = 0; i < 100; i++) {
      logger.debug("Iteration {}", i);
    }
  }

Again as you mention, without autoboxing, one would need to explicitly
convert the int to Integer. For example:

  if(logger.isDebugEnabled()) {
    for (int i = 0; i < 100; i++) {
      logger.debug("Iteration {}", new Integer(i));
    }
  }

The isXYZEnable methods ensure completeness in support for the case of
primitive data types. However, the API is not coherent as there is a
difference between the handling of Objects and primitive types.

In short, the current SLF4J API is complete but not coherent with
respect to the use case you mention. The cost of ensuring both
coherence and completeness looks prohibitive.


-- 
Ceki Gülcü

   The complete log4j manual: http://www.qos.ch/log4j/