commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Colebourne" <>
Subject Re: [id] util package
Date Mon, 31 May 2004 15:05:12 GMT
From: "Phil Steitz" <>
> > 1) Create one package scoped utils class in [id] with just the relevant
> > methods on it.
> Do you think that this is a good strategy in general?  What happens when
> bugs are found or efficiency is improved in the cut-and-pasted methods
> from the source component?  Do you cut-paste-modify test cases as well?
> So far, it seems that we are collectively OK with this when the amount of
> copied code is "small" and its state is "stable."  Do I have this right?
> What made me think we should keep the dependency in the present case is
> the number of classes and the fact that some of what is needed is in CVS

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).

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?

> 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.

> 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?


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

View raw message