In my last message, I failed to emphasize the brittleness of the "break into interfaces" hypothesis. Even if at a high-level of abstraction two APIs perform the same task, this does not mean that they can be abstracted away by a thin facade (or bridge). For example, all the attempts made at bridging X.25 and TCP/IP, both well defined and stable protocols, have failed miserably, even if both stacks supposedly fit into layers 1-4 of the 7 layer OSI network model.
The Logging problem has not been completely solved yet. Log4j will continue to evolve at a quick pace during the coming years. I believe that trying to foresee, let alone abstract this evolution is an iffy proposal at best.
Some will say that Logging is no where comparable in complexity of a network protocol. Some will say that JSR 47 cannot be ignored since it is part of the JDK. Some will say that they absolutely require API independence to satisfy their clients. I realize that asking you to take my word for it is too big a leap of faith. Consequently, and as in the past, I fully expect my repeated warnings to be ignored.
Coming back to your example, you are assuming that localization support will be done by introducing new member methods in the "logger" interface/ abstract class. However, this will not necessarily be the case. As Curt Arnold mentioned earlier, localization support can be added by adding new semantics to the existing methods. Of course, another logging API may choose another path where localization support is done through new specialized methods. Now, JCL's task is two abstract these two different approaches. Which even in the case of this quasi-trivial example looks extremely hard to get right. Hence my observation that in the case of evolving and divergent APIs, abstraction although desirable, is not feasible.
The interface vs. abstract class debate only makes sense in the case of APIs submitting to a common standard. In that case, the common standard should be implemented in terms of interfaces instead of abstract classes in order too leave enough wiggling room for willing implementations of the standard. However, even if you are right, since there is no common standard, the debate interface vs. abstract class is moot.
My personal attempts at a future-aware standard showed how difficult the abstraction task was. (I was only concerned with abstracting log4j's own interfaces.)
See also http://cvs.apache.org/viewcvs.cgi/logging-log4j/src/java/org/apache/ugli/
At 04:41 PM 12/20/2004, Matt Sgarlata wrote:
Let's make this more concrete by examining the problem currently presented to us: localization of logging messages (this would be API-X in your example). If JCL adds a new LocalizedLog interface (JCL-IX), calls to the localized log will work as expected when the underlying logging implementation supports localization (branch 1 in your post). If localization is not available, the unresolved message keys are supplied to the underlying logging implementation (branch 2).
This seems perfectly reasonable to me. If the underlying logging implementation doesn't support internationalization, then the log messages aren't internationalized. Of course, if you've gone to all the trouble of making your message internationalized, I would expect this would narrow down the field of logging implementations you chose from :)
I hope I'm not being argumentative or dense. I'm really just trying to make a case for using interfaces rather than abstract classes. My point earlier was simply that the more features are supported by JCL, the harder it will be to squeeze them into some type of abstract class hierarchy and the more compelling an interface-based abstraction layer is.
Matt
-- Ceki G�lc�
The complete log4j manual: http://qos.ch/log4j/
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
