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.
but in return will help consolidate Java logging, something which is sorely needed. It can be argued that SLF4J is an externally run project or that it is not directly in log4j's interest to implement SLF4J directly, in the mean time, log4j is becoming increasingly irrelevant as it vegetates. Your offer to review any patch or branch subject to your own personal criteria of backward compatibility is not exactly new nor alluring.
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.
Nothing has been new in this thread.
As I see it, as in the past, you will keep coming up with reasons to stall the project. Fortunately, with sufficient support from the other log4j committees, your approval can be dispensed with.
--------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
