http://bugzilla.slf4j.org/show_bug.cgi?id=31 --- Comment #76 from Ceki Gulcu <listid@qos.ch> 2009-12-27 12:04:56 --- Thanks for providing this view in support of maintain JDK 1.4 compatibility. Given that the dates for End of Service Life for any given JDK are chosen arbitrarily by Sun Inc., without consulting the java user-base, the EOSL date is not a binding deadline but a mere indication of Sun's own position with respect to a given JDK. Logging is often used to diagnose problems in an application. Moreover, in many software projects, SLF4J has many nodes pointing at it as a dependency, unfolding in a rather complex dependency graph. Given these two arguments, SLF4J has the obligation to be as stable as possible and maintain backward compatibility. Having emphasized the importance of backward compatibility, I also think that backward compatibility can become a trap on the long run. So, not only is evolution of the SLF4J API welcome, it is necessary. We need to find a way to satisfy those two contradictory constraints, namely compatibility and evolution. This is where exploratory works, such as your fork, come into play. -- Configure bugmail: http://bugzilla.slf4j.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.