John, This is a deep and tough question. The problem of binary compatibility is intrinsic to the nature of software. On one side, unlike other engineering endeavors, software can be easily modified and enhanced. On the other side, this make it very easy to break compatibility with previous versions of the software.
In widely used infrastructure libraries like log4j, the question of binary compatibility is singularly acute. It is not uncommon to see an application composed of several libraries each of which depends on log4j for its logging. If any two of these libraries depend on incompatible versions of log4j, the application may not run smoothly. In a library as large and wide as log4j, it is exceedingly difficult to preserve 100% backward compatibility between the oldest and newest versions. Nevertheless, changes that break binary compatibility are few and limited in scope such that the number of affected users is minimal. One notable exception is the deprecation of the Category class. If you read between the lines, the javadocs promise that the Category class will be kept around until mid-2003. This does not necessarily mean that it will be removed after that date� Our current policy forbids the removal of a deprecated field, method or class before two complete major release cycles elapse. In other words, a method deprecated in log4j 1.2 cannot be removed until version 1.5 is released, leaving developers over two years to adapt to changes in log4j. This policy applies to log4j version 1.2 and later. In earlier versions, the completion of only *one* release cycle was required for the removal of a deprecated method. I hope this answers the question and alleviates your concerns. At 11:04 06.06.2002 +0100, John Armstrong wrote: >What guarantees are there (if any) for binary compatibility between >different versions of log4j? > >We have recently had to upgrade from version 1.0.4 of log4j to version >1.1.3. I was surprised to notice that there was not complete binary >compatibility between these releases though fortunately it was easy to >change our code. However, the following situation could easily have arisen: > >Suppose library1 uses log4j 1.1.3 with its "Category.assert" method and >library2 uses "Category.assertLog" from log4j 1.2 the only solution is to >ask one of the library vendors to change their code. (Or to compile your own >hacked together log4j "version" with a both methods). > >My concern about this issue was increased when I saw in the javadocs that >Category is now deprecated and is scheduled for deletion next year. If and >when that happens won't a lot of libraries require conflicting versions of >log4j making it difficult to use log4j with code supplied from multiple >vendors? > >Thanks for any light you can shed on this, > >John -- 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]>
