http://bugzilla.slf4j.org/show_bug.cgi?id=31 John Vasileff <git@netcc.us> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |git@netcc.us --- Comment #89 from John Vasileff <git@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.