commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark R. Diggory" <mdigg...@latte.harvard.edu>
Subject Re: [Math] common-math and bloated 3rd party libraries
Date Wed, 05 Nov 2003 19:42:00 GMT
I'm trying organize this thread a little bit more than was accomplished 
in the discussion.

1.) Argument exists concerning the dependency requirements of Commons 
Math. To in fact be "modular" and "easily integrated" some discrepancy 
arises concerning interdependency with other commons components. The 
main question is; Are all these dependencies really required?

a.) logging: It sounds like a good idea to make logging a 
runtime/compile time dependency on only the test cases and not the main 
library. Is this logical to everyone? I really like the idea and as 
logging is really used "minimally" in only about 4 classes, this should 
be easy to work around.

b.) Some discussion arises concerning some of the "higher level" 
interfaces and their dependencies on commons such as Discovery. We 
should review and grade if this Discovery pattern will really of "true" 
value in the places we've applied it (As opposed to just providing 
simple method of instantiation on these object directly...)

c.) j2sdk1.3.1 vs. j2sdk1.4.1: we are a project in a group dedicated to 
providing tools that can operate in Java Servlet/EBJ environments. Many 
vendors are still operating on 1.3.1. We have concerns as to our stuff 
working there. Thus we need to make sure we use only mechanisms 
supported on 1.3.1 for the time being (and then operate on a longer 
timescale to determine how facilitate usage of 1.4.1 in the future). I 
think currently the big area is "Exception handling capabilities" and 
our primary solution was to use "o.a.l.e.NestedException.

2.) Server vs Application schools, I tend to think this is a "Red 
Herring", this arises primarily by some great comments Eric made

> Eric Pugh 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.  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!

a.) Even in a non-server environment, space isn't an issue, I think the 
real issue your seeing here is usage of "arcane" methods of setting up 
classpaths being approached by users of java programs as applications. 
All too often you come across the use of external scripting languages to 
manage execution of a java application. In the commons we have several 
efforts to alleviate this matter (CLI, Daemon,  Hivemind). Outside of 
commons theres Classworlds, Ant etc that provide solid means of building 
up classpathing more dynamically. There are smarter ways to buildup your 
classpath and initial environment than a batch script. In which case 
whether a class is in /lib/a.jar or /lib/b.jar become less of an issue.

b.) The places where space becomes an issue are things like Applets. 
(Yikes). And really when it boils down to it, There are enough solid 
tools out there for optimizing applets, you should optimize the hell out 
of whatever your building to produce the lightest applet you possibly 
can at "development time", this is very independent of the actually 
packaging of the dependencies  at development time. I don't think it 
something that the math project should limit ourselves by striving to 
provide.

I think thats about it for now.

Cheers,

-- 
Mark Diggory
Software Developer
Harvard MIT Data Center
http://osprey.hmdc.harvard.edu


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message