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 -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
