[slf4j-dev] [Bug 31] Varargs for Logger methods

[bugzilla-daemon at pixie.qos.ch]

http://bugzilla.slf4j.org/show_bug.cgi?id=31





--- Comment #55 from Joern Huxhorn <joern at huxhorn.de>  2009-11-14 17:45:22 ---
No, no, no, nobody *has* to change their slf4j-imports, It's entirely optional.
The original SLF4J-API would be left untouched.

The same is the case for binding. They would stay the same.
If a binding would not implement the new interface in addition to the old
interface then a wrapped instance would be returned.

Bindings that are already JDK1.5 only, like Logback, would have the *option* to
implement the new interface, making the wrapper unnecessary and thereby saving
a bit concerning both performance and memory-consumption. (That's the main
problem of my own implementation that's already working: It's very unlikely
that Logback will implement my interface ;)) 

What I have in mind is comparable to the Graphics vs. Graphics2D migration done
in Java - with one difference: My current plan is to *not* let n.Logger extend
o.Logger, simply to get rid of the unnecessary methods.

This does not break compatibility, though.
Both LoggerFactories and Loggers can co-exist, even in the same source file.

The additional cost of supporting parameterized logging and Throwable at the
same time is extremely cheap if there is no Throwable at the expected position.
Only the following conditions are evaluated:

        Throwable throwable=null;
        if(params != null)
        {
                int throwableIndex=params.length-1;
                if(throwableIndex >= 0 && (params[throwableIndex] instanceof
Throwable))
                {
                        // do additional work
                        // check that Throwable isn't used already
                        if(unused)
                        {
                                throwable = params[throwableIndex];
                                // reduce params, this is optional but cleaner
                                Object[] newParams=new Object[throwableIndex];
                                System.arraycopy(params, 0, newParams, 0,
throwableIndex);
                        }
                }
        }

As I explained before in #70 it's not about performance of exception logging
statements.

My main argument is consistency.

Stuff like being able to switch from logging without exception to logging with
exception - without having to change the whole log-message from parameterized
to non-parameterized.
Due to the current situation, we have the coding-guideline of *always*
surrounding every logging statement with an if(logger.isXXXEnabled()) statement
- simply to not forget it in case of exception logs.
Supporting Throwables in parameterized logging, on the other hand, would mean
that the aforementioned "if" wouldn't be necessary anymore for 99.5% of the
log-statements.
if(logger.isXXXEnabled()) would only be used if there was additional code
involved to create/prepare a rather complex and expensive logging-event, likely
at debug or trace-level.

Given that this bug has a severity of "blocker", I had the impression that you
were - again - actively looking for a good solution to this problem.

As we've discussed earlier, bumping SLF4J to 2.0 isn't a valid solution
since/if it breaks backwards compatibility.

The same is the case with my "tricky" suggestion of having both an JDK14 and
JDK15 version of the API because this would likely confuse users.

So it seems the only viable way to introduce this feature is what I suggested
above:
- thinking hard about how the logging API *should* look like if everyone had
JDK15.
- Defining that API in a new interface that exists side-by-side with the
original
- (ideally) deprecating the old interface in the very distant future.

My suggestion of using a new package name instead of new interface and class
names was meant to reduce the amount of work that is necessary if a complete
migration is *desired*.
In that case, only the imports would be changed by a global Search&Replace over
the whole code-base. But that's not necessary. No one is forced to do this.

And when I take a look at the CC-list of this ticket, I have the impression
that a certain amount of interest in this feature does exist.


-- 
Configure bugmail: http://bugzilla.slf4j.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.