commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark R. Diggory" <>
Subject Re: [Math] common-math and bloated 3rd party libraries
Date Wed, 05 Nov 2003 14:54:06 GMT
Hehehe, thats a novel idea. Ok to be devils advocate...

Your coming at this from  "one jar" perspective. Which leads me to 
wonder why having math be "one jar" is important to you? Can you please 
elaborate on this?

And to the rest of the community I postulate: Is this a critical usage case?

The commons libraries are planned/designed to be used together. So we 
make great gains in removing replicated effort by using them when the 
proper situation provides itself. Key word here "proper". Because in the 
long run, the circular dependency issues and usage of our math component 
also becomes critical to any group who doesn't wish to drag along a 
bunch of dependencies, and this may very well occur, even with another 
commons project using our library. So I'll go through and try to make 
some appropriate comments below.

Kasper Nielsen wrote:
> Hi gang,
> I love commons-math, one problem though!
> lets take a look at the dependecies
> common-lang: 189 kb
> commons-beanutils: 116 kb
> commons-collections-SNAPSHOT.jar 463
> commons-discovery 70 kb
> commons-logging-1.0.3.jar 31 kb kb
> Thats 850 kb!!! of 3rd party libraries that are only used in a few places.
> So to calculate a simple mean I need to include around 6 jars (including 
> commons-math)
> So lets get the list down a bit.
> * Commons-lang
> Getting rid of Commons-lang is pretty easy since it is only used in one 
> place: MathException
> Solution : Let MathException extend Exception instead of 
> NestableException. There aren't really anywhere we use the ability to 
> nest Exceptions inside other Exceptions in commons-math.
Really, I'm not so sure I really like NestableException now that I look 
at it. It just adds a whole bunch of complexity to the simple and 
integral idea that something throws an exception and you catch it. I'm 
not sure, but I think the idea of throwing the same exception object 
multiple times is just horrid. I wouldn't mind seeing it go away from 
our Exceptions. Others may think otherwise...

> * Commons-collections
> Getting rid of commons-collections is also pretty easy
> Solution: Getting a copy of HashBag (and the Testcase) and put into 
> math.util (no need to copy the interface)

Not so sure I'm into moving classes out of other commons projects and 
adding them to ours. HashBag is a fairly generic and useful class, 
chances are that if your using commons-math you'll probably also want to 
be using commons-collections.

> now we got rid of ~ 650 kb in around 2 minutes, 3 jars left, this is a 
> fun game!!
> * Commons-Beanutils
> Okay the transformers are nice but come on how many people are going to 
> use them?
> Solution: put them into a new small library: commons-math-transformers.jar

I'm thinking it would be just as easy to directly use the reflection api 
in our case.

> ** Commons-Discovery
> KISS keep it simple stupid, who on earth is going to provide there own 
> UnivariateRealSolverFactory??
> and for those few people that need it... I think they are smart enough 
> to do figure it out themself.
> Solution: remove it (or do something like we do for commons-logging)

Its also used to discover new distribution factories under 
o.a.m.stat.distributions Its interesting, I guess I don't understand 
what "discovery" really adds, as a feature, on top of Java's own Service 
Provider discovery? Anyways, is a pretty small library, I'm less 
inclined to chuck it because of the "bloat" issue.

> ** Commons-logging
> Lastly commons-logging...
> I would think returning NaN is enough, but okay if people insist we can 
> do something like (pseudo code)
> public class logutil
>    static Method logMethod;
>     static {
>         try
>         {
>             Class clazz = Class.forName("commons.LogFactory");
>             logMethod = clazz.getMethod("error");
>         }
>         catch (ClassNotFoundException e) {}
>     }
>     public static logError(String msg, Throwable t)
>     {
>         if (logMethod!=null)
>         {
>             logMethod.invoke(msg + t);
>         }
>     }
> }

Logging is a damn good thing to do in a standardized way, commons 
logging really provides a solid transitional api between commons tools 
and other logging api's. Its tiny, I'm not sure I think it's a great 
idea to replace it with custom code.

The above code scares me because reflection always adds a "layer" of 
complexity to stack traces and this type of approach makes it harder to 
interpret the logging and errors.

> and whoops we have now gotten rid of all the libraries, and we have easy 
> embeddable little commons math jar.
> regards
>   Kasper
> --------
> Kasper Nielsen
> kaspern at
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Mark Diggory
Software Developer
Harvard MIT Data Center

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

View raw message