Re: [Math] common-math and bloated 3rd party libraries

[__matthewHawthorne]

I, for one, like the idea of commons projects depending on each other 
when necessary.  There is always a lot of controversy with regards to 
"including another jar" that I don't quite understand.  I agree that if 
there are only 1 or 2 references, it may be reasonable to include the 
dependencies as package private classes, or make more of an effort to 
avoid them in the first place.  But this avoidance of code reuse 
sometimes disturbs me.

Are you short on disk space or something?  To me, 850 kb isn't really 
that much.



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.

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

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

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

** 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);
        }
    }
}
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 apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]