[slf4j-dev] [Bug 236] Use standard java.util.ServiceLoader for SLF4J Binding

[bugzilla-daemon at pixie.qos.ch]

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

--- Comment #4 from Thorsten <thorsten.Moeller at unibas.ch> 2011-09-05 11:32:27 CEST ---
(In reply to comment #3)
> Disadvantages of ServiceLoader
> 
> 3) ServiceLoader mechanism is actually more complex than the stupid static
> mechanism we currently have. Static binding is as stupid as it gets. It is
> therefore easy to understand for those willing to spend one or two mental
> cpu-cycles

Something that you also might want to keep in mind is that static binding as it
is currently implemented by SLF4J is "not compatible" with the Android
platform. Well, not totally incompatible but inducing the need to deviate from
the way SLF4J is used in Java standard edition. The point is that Andoid's
model implies that static bindings are resolved at build time of an application
rather than at deployment time. More precisely, build time here means not
compile time (which is part of build time) but postprocessing time as done by
the Dexer (which takes compiled bytecode and optimizes it; afterwards dex code
will be assembled into Android-specific application packages). Simply providing
the slf4j-api.jar and the jar file(s) of the logging binding that one wishes to
use (e.g., logback-*.jar) to the Dexer -- which is what an "uninformed"
developer would intuitively do -- does not work. 

There are, however, ways to resolve this issue. One way is to create
log-backend-specific "all-in-one" jars that contain SLF4J's API part minus the
dummy implementation(!) and the logger binding implementation. This is what is
essentially done by the SLF4J-Android project. However, this approach is
actually on top of the approach where one would completely build from sources
(i.e., applications include the source of the SLF4J API part and the logging
backend they wish to use). The downside is that they both require 

To conclude, a mechanism such as the META-INF/services one used by
ServiceLoader (and I suppose that OSGi mechanisms are conceptually the same)
would simplify and solve this issue, which is why I would opt for a more
dynamic binding mechanism. Anyway, the question is also whether having the
Android platform on board is actually considered important.

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