Ceki, Curt I suppose that this discussion is becoming too much personal. Please continue your discussion privately.
Antonio 2009/10/5 Ceki Gulcu <[email protected]>: > > > Curt Arnold wrote: >> >> On Oct 5, 2009, at 5:39 AM, Ceki Gulcu wrote: >> >>> Betrayal is a big word to associate with a facility, >>> i.e. ObjectRenderer, which hardly anyone uses, especially since there >>> are other ways of transforming an Object into a String. In a >>> widely-used project like log4j, it is easy to dig one's heels so as to >>> prevent change based on the backward compatibility argument. >> >>> >>> The changes I am proposing will affect an extremely small minority, >>> say less than 1 user in 100'000, >> >> Jess Holle immediately responded when the idea was floated that it would >> break his use of log4j. Usage questions on non-String first parameters >> comes up often enough on the mailing list that it cannot be just 1/100,000 >> of users. > > Jess Holle has indeed reacted pretty quickly. For any popular library, > there will be users who react negatively to proposed changes. The > 1/100'000 is probably too low an estimation. However, it is accurate to > say that the number of users who would benefit from logging > consolidation far outnumber those who would be negatively affected by > the Object->String change. It should also be noted that the > Object->String change does not mean that messages of type Object > cannot be passed to log4j. They just need to be passed differently. > >> I'm not aware of an Apache java compatibility statement, but Eclipse has >> one, http://wiki.eclipse.org/index.php/Evolving_Java-based_APIs. The >> technical description of binary compatibility in Java is described in >> http://java.sun.com/docs/books/jls/third_edition/html/binaryComp.html. The >> build.xml does CLIRR (http://clirr.sourceforge.net/). I do not believe I >> have ever made a backwards compatibility argument that went beyond those. > > In the context of an highly extensible framework like log4j, if > perfect backward compatibility were needed, it would be impossible to > change a single line of code. Careful compromises are needed to have > the log4j project evolve. > >> Nothing has been new in this thread. > > Yes. From the start it was clear that you were never going to change > your mind. Even when there were strictly *zero* backward compatibility > issues, you voiced strong opposition to adopting the SLF4J API or UGLI > as it was formerly called. I am hoping that the other log4j committers > will eventually realize that your stewardship of log4j, both in style > and substance, have been detrimental to the project. We might have > reached that point today, which would be something new in this > thread. > > I would also like to remind you that the position of chairperson > should be the subject of new elections from time to time. You have > been chairperson for Apache Logging for 4 years without organizing new > elections. > > -- > Ceki Gülcü > Logback: The reliable, generic, fast and flexible logging framework for > Java. > http://logback.qos.ch > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
