Someone recently claimed on a mailing list, on general@jakarta if I recall, that log4j interfaces were changing by the day. This is so patently untrue that I chose not to respond. Given the substantial number of log4j users, if we whimsically changed interfaces, the resulting uproar would be deafening.
Saying that log4j developers take backward compatibility seriously is an understatement. We can't afford not to. We are being watched not only by our users but by automated tools as well. Jakarta-gump (See http://jakarta.apache.org/gump/) checks and cross checks that different projects in and outside jakarta do not break dependents. For the results of the latest check see: http://jakarta.apache.org/builds/gump/latest/ (Log4j is the 8th listed project just after jakarta-ant.) Over one hundred (100) projects are thus cross checked every day. It is also fair to say that a few of those 100+ projects depend on log4j. In the past when log4j broke backward compatibility, gump quickly detected and reported the problem. Gump is one of our lines of defense, it is not the only the one. For example, log4j 1.1.x and 1.2 are compatible after serialization. (Gump does not check for this.) It is possible for a SocketServer running log4j 1.1 to receive events from a client running log4j 1.2 and conversely 1.2 servers to receive events from 1.1 clients even tough the LoggingEvent class changed between log4j 1.1 and 1.2. This compatibility did not happen by itself, it demanded work. Log4j 1.3 is likely to break serialization compatibility for performance reasons. By implementing the java.io.Externilizable interface instead of java.io.Serializable, on the wire transmission of LoggingEvents can be improved by a factor of 4, i.e. 400%. Although log4j 1.3 is slated to be 100% backward compatible with 1.2, it is unlikely to be serialization compatible. In other words, a client class compiled with log4j 1.2 will run perfectly with log4j-1.3.jar but a client using log4j-1.2.jar will not be able to talk to a 1.3 server. When log4j 1.3 is released some people will vocally declare that the heartless log4j developers deliberately broke backward compatibility without regard to user needs. It is a free Internet. Saying that log4j interfaces are not stable is grossly inaccurate. Very few users have complained about 1.1 / 1.2 changes. Existing log4j users who had trouble migrating to 1.2, are kindly invited to tell their horror stories. Success stories are equally welcome. At 12:14 12.06.2002 +0800, you wrote: >On Tuesday 19 March 2002 22:44, Rafael Alvarez wrote: > > Some may say that testcases written for Junit are easily modifiable > > with a text-replacing tools, and that's true. I'm just making a point. > >I can make another example; >JDK 1.4 introduced Throwable.getStackTrace(), which broke my binary >compatibility with 1.4 without my participation. I had that method in all my >exceptions that were part of a RMI call, > 50 classes all added up. > >The lower you get in the hierarchy (JDK at the bottom, log4j immediately on >top of that and the project at the very top), the more impact changes has on >other people. JDK is getting to the point where new methods can no longer be >added to non-final classes, as has otherwise been declared as Ok. > > > My point it: Perhaps some things will get deprecated, and you have to > > be prepared to it. Java is not always binary compatible itself, so > > stop bombing log4j > > </RANTING> > >Ceki, I can undertstand that you are "irritated" over this issue, but I can >also understand everyone's concern, as we are dealing with a VERY fundamental >service here. >I would like to suggest that one of the following approaches are taken; > >1. A declaration that if my code uses classes A, B and C directly, and >doesn't >subclass anything, compatibility will not be broken by the Log4J developers. > >2. A factory for obtaining the Logger, which is an interface only, a >method to >initialize the subsystem that doesn't reference the configurator classes >directly. And if I stick to these, I am guaranteed a binary functionality for >decades. > >3. Become a JDK logging framework replacement. > >Mistakes in the past doesn't have to be repeated, nor is the Log4J obliged to >un-do the binary breaks of the past. But expect a flight from Log4J if the >issue is ignored. > >Niclas -- Ceki SUICIDE BOMBING - A CRIME AGAINST HUMANITY Sign the petition: http://www.petitiononline.com/1234567b I am signatory number 22106. What is your number? -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
