commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <>
Subject Re: [id] util package
Date Mon, 31 May 2004 15:55:48 GMT
Stephen Colebourne wrote:
> From: "Phil Steitz" <>

> Small and stable is not a bad starting point for the definition. And yes,
> test cases may need to be copied too (however the copied classes may be
> tested as a result of testing part of [id] itself).

I agree.
> Each case will be different, and I haven't looked to see the exact details
> of [id]. If you look at [beanutils], one of the issues with removing a
> dependency later is when the dependency is in the public API. I doubt that
> that should be needed here, as the required code should just be internal,
> hence package scoped.
> Perhaps, a quick examination to see how many methods would be copied, and a
> guess at what %age of [codec] that is would help clarify?
I agree that this is what we need to do.
>>Out of curiousity, where would you put [math] in the scheme above? I
>>suppose there could be a "math-base" with no dependencies and a "math-app"
>>with some dependencies?
> Another way to look at it is whether the library does one thing or many.
> [betwixt] and [digeseter] process xml. They have, in essence a small API
> plus many supporting classes. Similarly, [jxpath] has a small public API
> (process xpath) with many classes to actually do the work. They are narrow
> API but deep within.
> [collections], [lang], [io] etc are broad API and shallow by constrast. Each
> class/method/utility can almost be used independently, making the jar file
> just a group of like-minded classes. I would suggest that [math] is more in
> this second category.

Interesting. I think I agree with this; though I am still not sure that 
"broad and shallow" can always mean "dependency-free."
>>I suppose that one solution would be to move Frequency into [collections].
>>  I know that sounds ridiculous. The point is that if we want to factor
>>components to minimize both dependencies and code duplication, and to keep
>>"low-level APIs" dependency-free, we might end up with a different set of
>>component boundaries than what we have now.
> [collections] already has Frequency by dint of the Bag interface. [math] is
> providing similar functionality but packaged for a maths library, and may
> make different assumptions. The simplest solution is probably to imaine that
> TreeBag doesn't exist - all it really is is a MutableInt/Integer class
> stored in a TreeMap. But I have to ask, should [math] be exposing someone
> else's API?

Well, the math-relevant part of Frequency is actually the discrete 
probability density and distribution functions that it exposes via the 
getPct(), getCumPct() methods (AARGH! -- just noticed the javadoc munges 
these.  One more thing to fix...).  This probably does not belong in 


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

View raw message