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

bugzilla-daemon at pixie.qos.ch bugzilla-daemon at pixie.qos.ch
Thu Sep 1 13:26:39 CEST 2011


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

--- Comment #3 from Ceki Gulcu <listid at qos.ch> 2011-09-01 13:26:38 CEST ---
Backward compatibility is always a very important issue but we are not there
yet. At this stage, we are trying to establish whether it makes *any* sense to
move to ServiceLoader. (BTW, pre-1.0 versions of SLF4J used a
provider-configuration file very similar to what ServiceLoader has.)

Davanum Srinivas mentioned via twitter the Aries SPI-Fly effort [1] in relation
to OSGi and ServiceLoader. The subject of binding services together is quite a
difficult one. We should weigh the pros and cons of any approach before
discarding it prematurely. Here are the pros and cons of ServiceLoader.

Advantages of ServiceLoader

1) it is "standard" in the sense that it's part of the JDK. 
2) it would allow for slightly a cleaner/simpler slf4j-api project module
structure

Disadvantages of ServiceLoader

1) JDK 1.6 required
2) downstream bindings would need to be updated (this a big disadvantage)
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

The question is whether there are other pros/cons.

[1] http://aries.apache.org/modules/spi-fly.html

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


More information about the slf4j-dev mailing list