I fully agree with the points you make - and thank you for clarifying the expected lifecycle of log4j.
Unfortunately your answer doesn't alleviate all my concerns. In a nutshell my problem is that using any third party software exposes code I release to risk and I am trying to evaluate the risk involved in using log4j. Until today I had thought of log4j as almost risk free because I had (completely stupidly) treated its API as having the same backwards compatibility as the standard Java APIs. I think I allowed myself to be hoodwinked by the fact that both sets of javadocs are written in the same shade of blue. Sadly for me I work in an industry where code often hangs around for millennia - I think the JDBC drivers we use are as old as JDBC itself for instance. Using any third party code exposes my code to risk. The question I am asking myself is "Would I be irresponsible if I released code into such an environment when I knew that the ongoing maintainability of that code is subject to the risk of unexpected API changes?". I think that the answer to this question is probably yes - and I know that I am not the only log4j user who has inadvertently opened themselves up to such a risk. The solution to the problem is pretty obvious - namely that some subset of log4j should be specially singled out as the core API with strong guarantees of backwards compatibility. The crux of the issue is whether or not the developers of log4j are willing to shoulder the burden of designing and maintaining such a core API. To get to the point I would really like the developers of log4j to say "We are willing to maintain x subset of our API forever with 100% backward compatibility". I understand completely why you would be reluctant to make such a commitment but I would like to try and tempt you: 1. For most users of log4j the only methods used are the logging methods of Category and Category.getInstance or the equivalent methods of Logger (this is based on supposition not research). So a core API that would satisfy such users would be tiny. 2. Sun has written a logging API for Java. So long as your core API is less functional than this you can benefit from the work they have done and steal their guarantees. 3. A key selling point of log4j over the new logging API for Java is the compatibility of log4j with different versions of Java - thus the users of log4j are very likely the kind of people who have cause to worry about interoperability. 4. Another key selling point of log4j is that it could be the de facto standard for logging in Java - in particular third party libraries are likely to use it allowing the logging to be unified in the application. Once again this is exactly the situation where concerns about interoperability are paramount. I hope you're tempted - or failing that I hope you can convince me that it wouldn't be irresponsible to use log4j in a JDBC driver with a 10 year life expectancy. -----Original Message----- From: Ceki G�lc� [mailto:[EMAIL PROTECTED]] Sent: 06 June 2002 12:34 To: Log4J Developers List Subject: Re: Binary compatibility between versions of log4j 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]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
