Well, you always have the option of not upgrading to newer versions of log4j. It sounds like that's the strategy you've chosen for JDBC drivers. Then what you need is a assurance that the old version you're using will continue to be maintained and have bugs fixed etc. That's a very different thing and one for which it will probably be easier to get a "guarantee".
Anders John Armstrong wrote: > 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]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
