John Armstrong wrote: > > Your question is in a different tense to mine. You ask: > > "For instance, what part or parts of log4j ARE binary incompatible?" > > My question is: > > "what part or parts of log4j MAY BECOME binary incompatible?" > > At present the answer to this question is apparently "any of log4j may > become binary incompatible". In two of your (Ceki's) responses you have > stressed that various pieces of log4j may not become binary incompatible, > but in saying this you seem to be very clearly reserving the right to break > binary compatability in the future. I want to know if there is any > possibility that your position on this point will change. > > I have made every attempt to define the problem clearly - if you tell me the > points I am being vague on I will be happy to clarify them. >
How about this for a start. The API for retrieving a Category / Logger and the API for logging and checking whether logging is enabled should be fixed for all time. Code which is going to be used in a variety of different situations which are outside the control of the original author will probably not use any of the API. e.g. Create an interface, or an abstract class which both Category and Logger extend which defines the log (..) and is...Enabled (..) methods. Provide an API which will return an instance of that type in a similar way to how Category/Logger does now. Guarantee that that API will never be change in such a way as to break backwards compatability. Modify all previous and current versions of log4j to support that API. This may take a little while but it will allow new code and old code to coexist. -- 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]>
