commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ceki Gülcü <>
Subject Re: [logging] ECL: Log interface vs. abstract class
Date Mon, 20 Dec 2004 17:28:30 GMT

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

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.

Ceki Gülcü

   The complete log4j manual:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message