logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anders Kristensen <akristen...@dynamicsoft.com>
Subject Re: Binary compatibility between versions of log4j
Date Thu, 06 Jun 2002 14:18:39 GMT
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".


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:ceki@qos.ch] 
> 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 
>>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,
> --
> Ceki
> Sign the petition: http://www.petitiononline.com/1234567b
> I am signatory number 22106. What is your number?
> --
> To unsubscribe, e-mail:   <mailto:log4j-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:log4j-dev-help@jakarta.apache.org>
> --
> To unsubscribe, e-mail:   <mailto:log4j-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:log4j-dev-help@jakarta.apache.org>

To unsubscribe, e-mail:   <mailto:log4j-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:log4j-dev-help@jakarta.apache.org>

View raw message