> From: Alex Karasulu [mailto:[EMAIL PROTECTED] > > Hi, > > I've been trying to get my hands around the Excalibur stuff > today because well the thread manager I use depends on it. I > really want to stop using deprecated ThreadPool interfaces > and the like. > > Could we take a vote to work with the commons folks who > already have a > thread pool package out there. I'm tired of having copies of > commons stuff. > > Granted some of it my have become redundant over time as > API's matured. > For an example of what I'm talking about take a look at the > ValuedEnum class in both framework and ValuedEnum in the > commons-lang project. The same > situation exists for many classes, CascadingExceptions Vs. > NestedExceptions > to utilities like ExceptionUtil Vs. ExceptionUtils and the > list goes on. > > If no one has any objections I would like to start replacing > these classes with the commons equivalents for A5. There is > no reason for us to duplicate these classes when the commons > does a nice job at it. I'm sure they would work with us to > migrate some of our functionality which really should be commons code.
Alex, good idea - duplication isn't a good thing. But consider other sources, since this is for A5 (which is a bit off still): - CascadingException -> Java 1.4 Exceptions are cascading without the need for any utility class: http://java.sun.com/j2se/1.4.2/docs/api/java/lang/Exception.html - ThreadPool -> util.concurrent has a ThreadPoolExecutor that later became the ThreadPool in java.util.concurrent in Java 1.5: http://gee.cs.oswego.edu/dl/concurrent/dist/docs/java/util/concurrent/Th readPoolExecutor.html Requiring JDK1.5 may be too much, but using the util.concurrent version would make for easier migration to 1.5 later. Just a thought - if we're going to break back-compat, we might as well clean up everythng we can. /LS --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
