This topic is getting hotter by the minute! I agree that binary compatibility between versions is something important, as it relieves the end user (us developers) from the tedious task of rewriting our app to conform to the latest spec.
BUT (and this is a big BUT here) you'll never know what will happen in the future. The JUnit project suffered a big impact when the assert keyword was introduced in jdk1.4 (the same case as log4j Category.assert() renamed to Category.assertLog()), as they had to change the assert() to assertTrue in one of his CORE classes to make it compatible with 1.4 (and that forced the rewriting of thousands of test all over the world from those who wanted to use the latest JUnit). Is the JUnit team responsible? I guess not. <RANTING STARTING - YOU CAN SKIP IT IF YOU WANT> 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. Another example is the servlet API. From 2.1 to 2.2 some methods got deprecated (HttpSession getValue() and setValue() came to mind). And some method in the Thread got deprecated, etc,etc. 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> What we can ask for is an stable subset of the core API (Like Logger and Level related stuff). Even more, a set of adapters can be created to solve compatibility issues and to help . That should solve most of the problems. As for using products that rely on different versions of log4j, well, you have the source code of all the milestone versions of log4j. Try to reconciliate them and recompile. Sadly that's a problem that plage all the software world. m2c, Rafael mailto:[EMAIL PROTECTED] P.S: If someone feels offended by this post, I offer my apologies. Sometimes I'm to blunt expressing my opinions. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
