> The need to support 1.3 is diminishing over time. Java 1.4 is available > and runs well on all the major platforms I can think of.
We should be careful with 1.3 vs. 1.4. From my POV, sadly, the majority of our customers run on a version WebSphere that only supports 1.3, which means that our product can't use 1.4. Very sad. I take the following perspective: basement libraries like Commons should be reasonably conservative (look at Ant's SDK reqs) while the products one writes on top of them can be more aggressive. *I* make the decision to ask our customers to use 1.4 vs 1.3. I should not be forced to do that. Gary > -----Original Message----- > From: David Graham [mailto:[EMAIL PROTECTED] > Sent: Wednesday, November 05, 2003 06:54 > To: Jakarta Commons Developers List > Subject: RE: [Math] common-math and bloated 3rd party libraries > > > --- Eric Pugh <[EMAIL PROTECTED]> wrote: > > 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. > > Agreed, especially because Jakarta's mission is to create *server* side > libraries. > > > 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.. > > In this case, it looks like commons-lang and commons-logging are only > needed because math doesn't use Java 1.4 as the base level. Moving to > Java 1.4 has the advantage of providing exception chaining and logging in > the Java core and eliminates 2 jars. Obviously, the disadvantage is that > 1.3 users can't use commons-math. > > The need to support 1.3 is diminishing over time. Java 1.4 is available > and runs well on all the major platforms I can think of. > > David > > > > > 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] > > > > > __________________________________ > Do you Yahoo!? > Protect your identity with Yahoo! Mail AddressGuard > http://antispam.yahoo.com/whatsnewfree > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED]
