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

[bugzilla-daemon at pixie.qos.ch]

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

John Vasileff <git at netcc.us> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |git at netcc.us

--- Comment #89 from John Vasileff <git at netcc.us> 2011-09-07 02:24:54 CEST ---
A new proposal (and code):

1. Release 2.0 targeting Java 5

Those stuck on 1.4 aren't looking for the latest and greatest features.
SLF4J 1.6.2 should be sufficient.


2. Add varargs with Google Collections/Guava style methods

log*(String format, String arg1, ..., String arg6)
log*(String format, String arg1, ..., String arg6, String... others)

There is a performance penalty for creating the implicit array required for
varargs.  A quick benchmark shows this to be about 1 nanosecond.  Small, but
why not eliminate it for nearly all use cases (6 or fewer args). As a bonus
with this approach, the existing one and two arg methods will fit in naturally
with this style API.  The log*(format, Object[] arg) methods should be retained
for compatibility.

This will require many new methods, but it is not as bad as it sounds.  See
below.


3. Maintain full (perpetual?) binary compatibility with legacy adapters.

Implement the new methods listed above in NamedLoggerBase.  All adapters
extending NamedLoggerBase will automatically have these methods when deployed
with the updated API.  The new methods will be final, so logger and adapter
implementations will never implement them.


4. Simplify the logger adapter contract

It seems that compatibility challenges may be largely due to the front end API
(used by application writers) is tightly bound to the adapter API (used by
logging platform developers).

The minimum set of methods required for an adapter is two (three if
LocationAwareLogger is implemented):

protected abstract boolean isEnabled(Marker marker, Level level);
protected abstract void log(Marker marker, Level level, String msg, Throwable
t);

An AbstractLogger class would implement all application facing API methods.
Recommending (or requiring) log adapters to extend AbstractLogger and implement
the two methods above would effectively unbind the front end and adapter APIs.
New Logger methods could be added.  Formatting would no longer be handled by
adapters.  Adapter lines of code and risk of bugs would be greatly reduced.

Loggers extending AbstractLogger would of course require the 2.0 API at
runtime, with the long term benefit of simplified code and future
compatibility.


An initial implementation for these items is availabe at:
https://github.com/jvasileff/slf4j/tree/topic-jdk5-varargs

There are two commits to look at.  The first covers #1, #2, and #3.  The second
adds #4.


John

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