(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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
