This backlash against multiple commons jars is happening in a lot of places.
However, I think it is a bit shortsighted.  If you are in a non server
environment, I understand the problem, but in a server environment with lots
of harddrive space, I don't.  Additionally, since in a server app you are
likely to need all thoses dependencies any way.  I think almost every app I
work on has commons-lang, commons-loggin, and commons-collections included.
And then depending on what else, commons-discovery and commons-beanutils
show up all the time!

By removing the dependency on commons-lang etc you also remove the ability
to leverage their code when something better comes out.  You end up copying
and pasting more and more out of all these projects in math.  And don't get
the benefit of the testing, bugfixing etc they go through..

Maybe a better approach is to try and figure out why things like
commons-collections are so big, and should they be shrunk down or partioned?

Eric

> -----Original Message-----
> From: Kasper Nielsen [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, November 05, 2003 2:55 PM
> To: [EMAIL PROTECTED]
> Subject: [Math] common-math and bloated 3rd party libraries
>
>
> 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]


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

Reply via email to