Rafael Alvarez wrote: > > 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. >
Thanks for explaining that, that is obviously a problem with the java compilers and not Junit, or log4j. It is possible for compilers to allow reserved words to be used as functions and variables when they are found in the 'correct' place which is something that Rexx (or one of its derivatives) does. However, there is an option to the JDK 1.4 compiler which allows it to use the old 1.3 syntax. Until such time as JUnit, or Log4j wanted to use the new syntax the old methods could have been kept and deprecated. > <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> > Deprecating a method is different to removing it. It merely acts as a warning that you shouldn't be using it. I do not know whether any deprecated method ever been removed from Java. > 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. > That is all that we are asking for. > 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. > Once you have the adapters sorted out it would be very easy to write versions of them for the different versions of log4j. -- This message may contain confidential information and will be protected by copyright. If this email isn't for you then we'd be grateful if you could notify Volantis by return and delete it. You should not copy, disclose or distribute any of its contents. Any reply may be read by the recipient to whom you send it and others within Volantis Systems Ltd. Although we aim to use efficient virus checking procedures we accept no liability for viruses and recipients should use their own virus checking procedures. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
