Gary Gregory wrote:
Yes, my last comment about 1.3.1 was probably a little extreme.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
Unfortunately, this is the challenge as more and more functionally separate libraries get "glopped" into the j2sdk core without any release as separately downloadable components. Suns Logging should have been a logically separate component that one should be able to add onto 1.3.1
-----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]
-- Mark Diggory Software Developer Harvard MIT Data Center http://www.hmdc.harvard.edu
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
