commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From __matthewHawthorne <ma...@phreaker.net>
Subject Re: [codec] More thoughts on CharSets and Encoders (references: R E: [codec] Streamable Codec Framework)
Date Fri, 16 Jan 2004 03:41:02 GMT
Gary Gregory wrote:
> (2) What could be done, and please forgive my lack of intimacy with these
> APIs, is to create [codec] APIs that are forward compatible to any extent
> possible. What I mean by this if NIO has a class Foo with methods a() and
> b(Foo) is to create an equivalent [codec] class Bar with methods a() and
> b(Bar), which would allow one to do search and replace in the future. This
> is quite a stretch I know, but guess what, we've done this at work in the
> logging domain (we have our own logging which we want to eventually move to
> 1.4 or log4j).


An alternative to the search-and-replace could be to create an interface 
which defines the requirements of the functionality that you need.  You 
could then provide a default implementation of the interface, use the 
Factory pattern to obtain instances, and then in the future, plug in an 
implementation which delegates to the corresponding 1.4 class once it 
becomes available in jakarta-land.

This could make things transparent to the outside.  I've been able to 
pull this off a few times when I was in the 1.3 to 1.4 transition (I had 
my own logger too), and I've also been able to plug trash my home-grown 
solutions in favor of swift libraries such as [dbcp] and [betwixt].

Maybe this is what you were saying and I misunderstood you.  Either way, 
it's painful to not be able to use 1.4, especially with 1.5's new tricks 
on the horizon. ;)


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message