Re: [Math] common-math and bloated 3rd party libraries
I only came across JRat[1] yesterday evening. I haven't experimented
with it yet but its on my todo list.
-John K
[1] http://jrat.sourceforge.net
On 17 Nov 2003, at 18:04, Mark R. Diggory wrote:
Very true, but are there any Open Source projects or initiatives to
standardize this sort of approach already? For example, here is a
project, I'm not sure of its current state (is about a year since
anything was done to it).
http://jiapi.sourceforge.net/
Also, does JMX relate at all to this use case?
http://java.sun.com/products/JavaManagement/
In other words is there any sort of standardized approach to
managing runtime event debugging in Java?
-Mark
Inger, Matthew wrote:
Not really a runtime dependency. You would merely use
a class loader which would have BCEL instrument your code.
Your code would have have no clue about anything that's
being done to it, and you could easily write your code
generically enough to plug in an arbitrary classloader.
Here's a main program which replaces the classloader,
and calls another main program. Think of it as a wrapper
script.
public static void main(String[] args)
throws Exception
{
// This is where you would construct your class loader
// Done generically enough, you could specify a classloader
// on the command line, and construct it here using
reflection.
ClassLoader myClassLoader =
Thread.currentThread().getContextClassLoader();
final int realClassNameIndex = 0;
String realClassName = args[realClassNameIndex];
int realArgsLength = args.length - realClassNameIndex - 1;
String realClassArgs [] = new String[realArgsLength];
System.arraycopy(args, realClassNameIndex + 1,
realClassArgs, 0,
realArgsLength);
Class clazz = myClassLoader.loadClass(realClassName);
Method m = clazz.getDeclaredMethod(main,
new Class[] { args.getClass() });
m.invoke(null, new Object[] { realClassArgs });
}
-Original Message-
From: Tomasz Pik [mailto:[EMAIL PROTECTED]
Sent: Monday, November 17, 2003 12:03 PM
To: Jakarta Commons Developers List
Subject: Re: [Math] common-math and bloated 3rd party libraries
Mark R. Diggory wrote:
I know there were a means to setup logging for debugging without
actually having to bury your code in logging lines... I've actually
seen packages like BCEL used to transform the classes in such a way
as to inject logging lines into bytecode, its a pretty slick idea,
but also has the overhead of learning how to use BCEL to manipulate
the bytecode base without screwing with the actual algorithm
behavior.
AspectJ?
But it introduces another runtime dependency...
Tomek
-Mark
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Mark Diggory
Software Developer
Harvard MIT Data Center
http://osprey.hmdc.harvard.edu
-
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]
Re: [Math] common-math and bloated 3rd party libraries
A few more:
http://pharos.inria.fr/Java/query.jsp?cids=c_2203hist=cids%3Dc_2154
Mark R. Diggory wrote:
Good documentation, good project activity. Documentation for how to plug
it in under tomcat and other application servers. Nice separation of
hooks, logging and monitoring into separate layers...
worth a try I think :-)
thanks
John Keyes wrote:
I only came across JRat[1] yesterday evening. I haven't experimented
with it yet but its on my todo list.
-John K
[1] http://jrat.sourceforge.net
On 17 Nov 2003, at 18:04, Mark R. Diggory wrote:
Very true, but are there any Open Source projects or initiatives to
standardize this sort of approach already? For example, here is a
project, I'm not sure of its current state (is about a year since
anything was done to it).
http://jiapi.sourceforge.net/
Also, does JMX relate at all to this use case?
http://java.sun.com/products/JavaManagement/
In other words is there any sort of standardized approach to
managing runtime event debugging in Java?
-Mark
Inger, Matthew wrote:
Not really a runtime dependency. You would merely use
a class loader which would have BCEL instrument your code.
Your code would have have no clue about anything that's
being done to it, and you could easily write your code
generically enough to plug in an arbitrary classloader.
Here's a main program which replaces the classloader,
and calls another main program. Think of it as a wrapper
script.
public static void main(String[] args)
throws Exception
{
// This is where you would construct your class loader
// Done generically enough, you could specify a classloader
// on the command line, and construct it here using reflection.
ClassLoader myClassLoader =
Thread.currentThread().getContextClassLoader();
final int realClassNameIndex = 0;
String realClassName = args[realClassNameIndex];
int realArgsLength = args.length - realClassNameIndex - 1;
String realClassArgs [] = new String[realArgsLength];
System.arraycopy(args, realClassNameIndex + 1,
realClassArgs, 0,
realArgsLength);
Class clazz = myClassLoader.loadClass(realClassName);
Method m = clazz.getDeclaredMethod(main,
new Class[] { args.getClass() });
m.invoke(null, new Object[] { realClassArgs });
}
-Original Message-
From: Tomasz Pik [mailto:[EMAIL PROTECTED]
Sent: Monday, November 17, 2003 12:03 PM
To: Jakarta Commons Developers List
Subject: Re: [Math] common-math and bloated 3rd party libraries
Mark R. Diggory wrote:
I know there were a means to setup logging for debugging without
actually having to bury your code in logging lines... I've actually
seen packages like BCEL used to transform the classes in such a way
as to inject logging lines into bytecode, its a pretty slick
idea, but also has the overhead of learning how to use BCEL to
manipulate the bytecode base without screwing with the actual
algorithm behavior.
AspectJ?
But it introduces another runtime dependency...
Tomek
-Mark
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Mark Diggory
Software Developer
Harvard MIT Data Center
http://osprey.hmdc.harvard.edu
-
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]
--
Mark Diggory
Software Developer
Harvard MIT Data Center
http://osprey.hmdc.harvard.edu
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Math] common-math and bloated 3rd party libraries
J.Pietschmann wrote:
Paul Libbrecht wrote:
a.) logging:
I don't really agree here. I do think it is very useful for any system
to be able to raise a logging verbosity at any-time so that bugs and
misunderstandings can be tracked.
It depends on the complexity of the stuff potentially being prepared
for logging. I don't think [math] is already complex enough that
built-in logging is warranted. The implemented algorithms should be
reasonably fail-safe for the most part. Failures could be sensibly
handled with exceptions, and data for tracking down the problem (e.g.
convergence problems in the solver) should be available. If not, this
should be corrected of course.
The issues where I found Logging occurring where in situations such as
this catch in GammaDistributionImpl
/**
* For this disbution, X, this method returns P(X le; x).
* @param x the value at which the PDF is evaluated.
* @return PDF for this distribution.
*/
public double cummulativeProbability(int x) {
double ret;
if (x 0) {
ret = 0.0;
} else if (x = getNumberOfTrials()) {
ret = 1.0;
} else {
try {
ret = 1.0 - Beta.regularizedBeta(getProbabilityOfSuccess(),
x + 1.0, getNumberOfTrials() - x);
} catch (MathException ex) {
LogFactory.getLog(getClass()).error(
Failed to compute cummulative probability,
returning NaN.,ex);
ret = Double.NaN;
}
}
return ret;
}
I removed instances of this Logging entry in an earlier commit. I think
awhile back there was allot of discussion about if this should throw an
exception or return NaN. The origin of this exception is a Convergence
Exception in ContinuedFraction. The big question is the same as before,
should this convergence exception be passed out and handled by the
application or should it be suppressed internally the way it is here?
-Mark
--
Mark Diggory
Software Developer
Harvard MIT Data Center
http://osprey.hmdc.harvard.edu
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Math] common-math and bloated 3rd party libraries
Mark R. Diggory wrote: I removed instances of this Logging entry in an earlier commit. I think awhile back there was allot of discussion about if this should throw an exception or return NaN. The origin of this exception is a Convergence Exception in ContinuedFraction. The big question is the same as before, should this convergence exception be passed out and handled by the application or should it be suppressed internally the way it is here? As a developer I would like to get it configurable. But I guess I'd be hated by people of requesting so... Returning NaN is almost certain to raise some exception later, or ? Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Math] common-math and bloated 3rd party libraries
Paul Libbrecht wrote: Mark R. Diggory wrote: I removed instances of this Logging entry in an earlier commit. I think awhile back there was allot of discussion about if this should throw an exception or return NaN. The origin of this exception is a Convergence Exception in ContinuedFraction. The big question is the same as before, should this convergence exception be passed out and handled by the application or should it be suppressed internally the way it is here? As a developer I would like to get it configurable. But I guess I'd be hated by people of requesting so... Returning NaN is almost certain to raise some exception later, or ? Paul That sounds kinda cynical ;-) My ultimate sentiment is to just get it passed on out and let the application manage exceptions dealing with non-convergence. Maybe thats the simplest possible comprimise? Then the user can decide what they will do when convergence fails instead of having the application suppress the exception and force them to test for NaN conditions all the time? -M. -- 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]
Re: [Math] common-math and bloated 3rd party libraries
Mark R. Diggory wrote: Paul Libbrecht wrote: Mark R. Diggory wrote: I removed instances of this Logging entry in an earlier commit. I think awhile back there was allot of discussion about if this should throw an exception or return NaN. The origin of this exception is a Convergence Exception in ContinuedFraction. The big question is the same as before, should this convergence exception be passed out and handled by the application or should it be suppressed internally the way it is here As a developer I would like to get it configurable. But I guess I'd be hated by people of requesting so... Returning NaN is almost certain to raise some exception later, or ? That sounds kinda cynical ;-) By no means ! My ultimate sentiment is to just get it passed on out and let the application manage exceptions dealing with non-convergence. Maybe thats the simplest possible comprimise? Then the user can decide what they will do when convergence fails instead of having the application suppress the exception and force them to test for NaN conditions all the time? But I would expect that it is not the application itself and not even the user which will receive the NaN but some other, say a graph-component (they should be quite happy with that), or something else... I had a case recently where I made a little integrer calculator offering +-*/ within a kind of console. And it turned out was important for this usage to have a message that said that the 7 was not dividable by 3. Having NaN somewhere (hence everywhere with these operations) would have just told the user something like Huh ?. (plus some people tend even to indicate wether this is positive-zero or negative-zero (when doing elementary limits) which would yeald us positive-NaN or negative-NaN !!). But maybe I'm going too far... sorry... Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Math] common-math and bloated 3rd party libraries
Paul Libbrecht wrote: Mark R. Diggory wrote: Paul Libbrecht wrote: Mark R. Diggory wrote: I removed instances of this Logging entry in an earlier commit. I think awhile back there was allot of discussion about if this should throw an exception or return NaN. The origin of this exception is a Convergence Exception in ContinuedFraction. The big question is the same as before, should this convergence exception be passed out and handled by the application or should it be suppressed internally the way it is here As a developer I would like to get it configurable. But I guess I'd be hated by people of requesting so... Returning NaN is almost certain to raise some exception later, or ? That sounds kinda cynical ;-) By no means ! My ultimate sentiment is to just get it passed on out and let the application manage exceptions dealing with non-convergence. Maybe thats the simplest possible comprimise? Then the user can decide what they will do when convergence fails instead of having the application suppress the exception and force them to test for NaN conditions all the time? But I would expect that it is not the application itself and not even the user which will receive the NaN but some other, say a graph-component (they should be quite happy with that), or something else... I had a case recently where I made a little integrer calculator offering +-*/ within a kind of console. And it turned out was important for this usage to have a message that said that the 7 was not dividable by 3. Having NaN somewhere (hence everywhere with these operations) would have just told the user something like Huh ?. (plus some people tend even to indicate wether this is positive-zero or negative-zero (when doing elementary limits) which would yeald us positive-NaN or negative-NaN !!). But maybe I'm going too far... sorry... Paul No, not too far at all, thats a great usage example for why exceptions here may be more beneficial in the long run! -- 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]
Re: [Math] common-math and bloated 3rd party libraries
--- Mark R. Diggory [EMAIL PROTECTED] wrote: I'm trying organize this thread a little bit more than was accomplished in the discussion. Thanks, Mark. Good job. 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 +1 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...) +1 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 +1 2.) Server vs Application schools, I tend to think this is a Red Herring, this arises primarily by some great comments Eric made I also think that if we do a good job addressing points 1a and 1b above, the issue of requiring or having dependencies on too many other jars will be ameliorated by simply having reduced the number upon which math depends. Al __ 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]
Re: [Math] common-math and bloated 3rd party libraries
Al Chou wrote: 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 +1 I don't really agree here. I do think it is very useful for any system to be able to raise a logging verbosity at any-time so that bugs and misunderstandings can be tracked. Depending on commons-logging really isn't much, or is it ?? (it's applet friendly btw!). Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Math] common-math and bloated 3rd party libraries
On Wed, 5 Nov 2003, Mark R. Diggory wrote: Hmm, not to be critical, but 5.1 is almost at the end of its product lifecycle. Weblogic has had several releases since 5.1 that solve many of these issues do they not? I say this mostly to identify that there is a limitation as to how far back in terms of versioning we, as a new tool, should consider supporting. I would have attempted to deal with an issue like this with BEA, not neccessarily with the java community at large because they create too many jars (I'm saying this lightly). Not to nip a subject in the butt. But this has moved way off the issue associated with how dependent the different commons projects (and specifically related to math dependencies). I hope we can draw it back into this subject. -Mark I agree with minimizing the number of dependent Jar's. I also agree with statements made earlier in this thread related to supporting older JDKs (if JDK1.2 works for your app why should use of this component force you to change?) Regarding the logging; It has been suggested that the logging dependency be isolated to the test classes only on not required for the runtime lib. This makes sense to me, with the caveat that we must have a robust exception hierarchy so that logging can be plugged in at a higher level. Regarding the Discovery, I see only two instances where the DiscoveryClass is used (UnivariateRealSolverFactory, and DistributionFactory), both of which use only the newInstance(Class,String) method. Off hand I dont see the advantage of using the DiscoveryClass here, my impression is the find() methods are the 'meat' of the DiscoveryClass. commons-collections, this seems only prudent to keep, as I can only imagine that the linear algebraic routines will become more complicated, and collections lends itself naturally to mathematical constructs. this leaves commons-lang, and commons-beanutils None of these are used very extensively, however I can see how these are useful. commons-lang is used only in the MathException class, as a trade off for removing logging I think that the NestableException becomes necessary. commons-beanutils is used by the *Transformer classes (seems good to me). -- Matt Cliff Cliff Consulting 303.757.4912 720.280.6324 (c) The label said install Windows 98 or better so I installed Linux. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[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]
Re: [Math] common-math and bloated 3rd party libraries
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]
Re: [Math] common-math and bloated 3rd party libraries
On Wednesday, November 5, 2003, at 09:26 AM, __matthewHawthorne wrote: 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. Reuse where the price of reuse is lower than the price of a better design is fine, but here the better design cost is negligible. Don't add dependencies unless you really need them, please. Why does a math module depend on a logging module for deployment? Have the unit tests log, not the math functions. =) -Brian PGP.sig Description: This is a digitally signed message part
RE: [Math] common-math and bloated 3rd party libraries
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]
Re: [Math] common-math and bloated 3rd party libraries
Hehehe, thats a novel idea. Ok to be devils advocate...
Your coming at this from one jar perspective. Which leads me to
wonder why having math be one jar is important to you? Can you please
elaborate on this?
And to the rest of the community I postulate: Is this a critical usage case?
The commons libraries are planned/designed to be used together. So we
make great gains in removing replicated effort by using them when the
proper situation provides itself. Key word here proper. Because in the
long run, the circular dependency issues and usage of our math component
also becomes critical to any group who doesn't wish to drag along a
bunch of dependencies, and this may very well occur, even with another
commons project using our library. So I'll go through and try to make
some appropriate comments below.
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.
Really, I'm not so sure I really like NestableException now that I look
at it. It just adds a whole bunch of complexity to the simple and
integral idea that something throws an exception and you catch it. I'm
not sure, but I think the idea of throwing the same exception object
multiple times is just horrid. I wouldn't mind seeing it go away from
our Exceptions. Others may think otherwise...
* 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)
Not so sure I'm into moving classes out of other commons projects and
adding them to ours. HashBag is a fairly generic and useful class,
chances are that if your using commons-math you'll probably also want to
be using commons-collections.
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
I'm thinking it would be just as easy to directly use the reflection api
in our case.
** 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)
Its also used to discover new distribution factories under
o.a.m.stat.distributions Its interesting, I guess I don't understand
what discovery really adds, as a feature, on top of Java's own Service
Provider discovery? Anyways, is a pretty small library, I'm less
inclined to chuck it because of the bloat issue.
** 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);
}
}
}
Logging is a damn good thing to do in a standardized way, commons
logging really provides a solid transitional api between commons tools
and other logging api's. Its tiny, I'm not sure I think it's a great
idea to replace it with custom code.
The above code scares me because reflection always adds a layer of
complexity to stack traces and this type of approach makes it harder to
interpret the logging and errors.
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]
--
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]
Re: [Math] common-math and bloated 3rd party libraries
Brian McCallister wrote: On Wednesday, November 5, 2003, at 09:26 AM, __matthewHawthorne wrote: Why does a math module depend on a logging module for deployment? Have the unit tests log, not the math functions. =) -Brian Bright Idea...I hadn't really thought about that. :-) -- 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]
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]
Re: [Math] common-math and bloated 3rd party libraries
David Graham wrote: 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 And really, in the long run, if your developing and your stuck back on 1.3.1, you have alot greater issues to be focusing on then adding a new library to your tool. If your not focusing on making the transition off an older obsolete JVM , your not going to be able to run on current platforms. Specifically, why should we tailor our packages for your obsolete code? -Mark -- 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]
RE: [Math] common-math and bloated 3rd party libraries
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
RE: [Math] common-math and bloated 3rd party libraries
I also like the idea of clearly established dependencies.
It would be nice for example, if we could slice and dice [lang] and
[collections] such that they could depend on a core set of jars.
Gary
-Original Message-
From: __matthewHawthorne [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 05, 2003 06:27
To: Jakarta Commons Developers List
Subject: Re: [Math] common-math and bloated 3rd party libraries
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]
Re: [Math] common-math and bloated 3rd party libraries
Gary Gregory wrote:
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.
Yes, my last comment about 1.3.1 was probably a little extreme.
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
RE: [Math] common-math and bloated 3rd party libraries
On Wed, 5 Nov 2003 06:54:14 -0800 (PST), David Graham [EMAIL PROTECTED] said: Agreed, especially because Jakarta's mission is to create *server* side libraries. [...] 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. While I tend to be in the go with 1.4 camp, this is MUCH easier tent to pitch in NON-server environments. Commercial J2EE containers tend to be dinosaurs with respect to JDK versions, and commercial users of said containers tend to be dinosaurs too. So I typically see sites that are a couple versions behind in upgrading their container, so their developers are stuck back in 1.3-land. I also want to gripe mildly about the server-side mission, since it feels myopic to me. The lines between client and server blur more every day. With JNLP it is easy and beneficial to shove increasing functionality to the client side, which means downloading jars to the desktop. Cheers, .T. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Math] common-math and bloated 3rd party libraries
FWIW the math proposal actually says: Emphasis on small, easily integrated components rather than large libraries with complex dependencies ;-) As far as Todds comments go: While I tend to be in the go with 1.4 ... I'm firmly in the stick with 1.3 camp. Until there is either progress which is *really* blocked by lack of access to 1.4+ and or the demand for 1.3 compatibility is insignificant I don't think it is wise for any Jakarta sub-project, or part of commons, to ignore the fact that the Jakarta mission to produce server software, and many many people are stuck with 1.3 until they can justify significant investment involved in upgrading to newer container version. Don't forget that the cost of change isn't all in the software there's a big old load of testing to do as well. I also want to gripe mildly about the server-side mission, since it feels myopic to me. The lines between client and server blur more every day. With JNLP it is easy and beneficial to shove increasing functionality to the client side, which means downloading jars to the desktop. But the lines are blurred and blurring @jakarta as well, there's plenty of software here which is as applicable in clients as it is in servers, but to extend the scope of the project to anything java at all would be silly, theres already enough going on as it is. If you want to develop desktop software @apache, make a proposal to the incubator. d. *** The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient (or responsible for delivery of the message to the intended recipient) please notify us immediately on 0141 306 2050 and delete the message from your computer. You may not copy or forward it or use or disclose its contents to any other person. As Internet communications are capable of data corruption Student Loans Company Limited does not accept any responsibility for changes made to this message after it was sent. For this reason it may be inappropriate to rely on advice or opinions contained in an e-mail without obtaining written confirmation of it. Neither Student Loans Company Limited or the sender accepts any liability or responsibility for viruses as it is your responsibility to scan attachments (if any). Opinions and views expressed in this e-mail are those of the sender and may not reflect the opinions and views of The Student Loans Company Limited. This footnote also confirms that this email message has been swept for the presence of computer viruses. ** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Math] common-math and bloated 3rd party libraries
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Math] common-math and bloated 3rd party libraries
Mark wrote: 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! I think that this comment is a little shortsighted. We are still using weblogic 5.1 and constantly have problems with the multitude of third party libraries that we are using. WL 5.1 does not seem to find libraries in the WEB-INF/lib directory, as it should, so these have to be set using the classpath. Unfortunately, on Windows NT, the commandline has a size limitation. Every so often, after adding another library, we are unable to start the server due to a the command is too long error. This is a PITA and we have been working around it for several years. Having to add 3 or 4 extra commons jars just because I want to use ONE of the libraries is lame. I'm all for code reuse but it seems as if the commons developers have created alot of unnecessary dependancies between the projects (maybe as a show of solidarity, who knows). This also creates versioning problems. If I want to update one library, I may have to update several of it's dependant libraries, ad nauseum. I already deal with this hassle with the rapidly changing XML libraries and the fact that some idiot library developers insist on including dated versions of the dom and sax api's in their jars. /rant People need to realize that there are lots of legacy users out there who aren't limited by only 'harddrive space'. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Math] common-math and bloated 3rd party libraries
--- Charles Hudak [EMAIL PROTECTED] wrote: Mark wrote: 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! I think that this comment is a little shortsighted. We are still using weblogic 5.1 and constantly have problems with the multitude of third party libraries that we are using. WL 5.1 does not seem to find libraries in the WEB-INF/lib directory, as it should, so these have to be set using the classpath. Unfortunately, on Windows NT, the commandline has a size limitation. Every so often, after adding another library, we are unable to start the server due to a the command is too long error. This is a PITA and we have been working around it for several years. Having to add 3 or 4 extra commons jars just because I want to use ONE of the libraries is lame. I agree that packages should limit dependencies and I sympathize with your problems. However, you're using a broken container on a lame desktop OS. Trying to work around issues like this is *way* out of scope for commons packages. David I'm all for code reuse but it seems as if the commons developers have created alot of unnecessary dependancies between the projects (maybe as a show of solidarity, who knows). This also creates versioning problems. If I want to update one library, I may have to update several of it's dependant libraries, ad nauseum. I already deal with this hassle with the rapidly changing XML libraries and the fact that some idiot library developers insist on including dated versions of the dom and sax api's in their jars. /rant People need to realize that there are lots of legacy users out there who aren't limited by only 'harddrive space'. - 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]
[OT] Re: [Math] common-math and bloated 3rd party libraries
Sorry for a little offtopic post. Charles Hudak wrote: I think that this comment is a little shortsighted. We are still using weblogic 5.1 and constantly have problems with the multitude of third party libraries that we are using. WL 5.1 does not seem to find libraries in the WEB-INF/lib directory, as it should, so these have to be set using the classpath. Unfortunately, on Windows NT, the commandline has a size limitation. Every so often, after adding another library, we are unable to start the server due to a the command is too long error. This is a PITA and we have been working around it for several years. Check if your library names contains dots. We've found that something like this-is-a-library-2.1.jar won't work on some versions of WebLogic. After renaming to this-is-a-library-2_1.jar it works. Regards, Tomek - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Math] common-math and bloated 3rd party libraries
Charles Hudak wrote: Mark wrote: 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! I think that this comment is a little shortsighted. Maybe we all need new glasses ;-) We are still using and constantly have problems with the multitude of third party libraries that we are using. WL 5.1 does not seem to find libraries in the WEB-INF/lib directory, as it should, so these have to be set using the classpath. Unfortunately, on Windows NT, the commandline has a size limitation. Every so often, after adding another library, we are unable to start the server due to a the command is too long error. This is a PITA and we have been working around it for several years. Having to add 3 or 4 extra commons jars just because I want to use ONE of the libraries is lame. I'm all for code reuse but it seems as if the commons developers have created alot of unnecessary dependancies between the projects (maybe as a show of solidarity, who knows). This also creates versioning problems. If I want to update one library, I may have to update several of it's dependant libraries, ad nauseum. I already deal with this hassle with the rapidly changing XML libraries and the fact that some idiot library developers insist on including dated versions of the dom and sax api's in their jars. /rant People need to realize that there are lots of legacy users out there who aren't limited by only 'harddrive space'. Hmm, not to be critical, but 5.1 is almost at the end of its product lifecycle. Weblogic has had several releases since 5.1 that solve many of these issues do they not? I say this mostly to identify that there is a limitation as to how far back in terms of versioning we, as a new tool, should consider supporting. I would have attempted to deal with an issue like this with BEA, not neccessarily with the java community at large because they create too many jars (I'm saying this lightly). Not to nip a subject in the butt. But this has moved way off the issue associated with how dependent the different commons projects (and specifically related to math dependencies). I hope we can draw it back into this subject. -Mark -- Mark Diggory Software Developer Harvard MIT Data Center http://osprey.hmdc.harvard.edu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Math] common-math and bloated 3rd party libraries
David Graham wrote: --- Charles Hudak [EMAIL PROTECTED] wrote: Mark wrote: 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! I think that this comment is a little shortsighted. We are still using weblogic 5.1 and constantly have problems with the multitude of third party libraries that we are using. WL 5.1 does not seem to find libraries in the WEB-INF/lib directory, as it should, so these have to be set using the classpath. Unfortunately, on Windows NT, the commandline has a size limitation. Every so often, after adding another library, we are unable to start the server due to a the command is too long error. This is a PITA and we have been working around it for several years. Having to add 3 or 4 extra commons jars just because I want to use ONE of the libraries is lame. I agree that packages should limit dependencies and I sympathize with your problems. However, you're using a broken container on a lame desktop OS. Trying to work around issues like this is *way* out of scope for commons packages. I agree with your assessment of that platform; but your comment raises an interesting question: to what extent should commons component design decisions be influenced by characteristics of the user base. My opinion is lots. Lame and broken as it may be, WebLogic 5 on NT has a large installed base = lots of potential commons users. Similarly, WebSphere 3 (JDK - sic - 1.2.2) and WebSphere 4 (JDK 1.3.1) are huge. Most of these folks have do not have the luxury of choosing their deployment targets and they often have limited control over their deployment environments. I think that it is very reasonable to try to make things as easy as possible for them. I also agree with Danny's observation above that for commons-math in particular, the commitment in the proposal was to keep dependencies to a minimum. Phil David I'm all for code reuse but it seems as if the commons developers have created alot of unnecessary dependancies between the projects (maybe as a show of solidarity, who knows). This also creates versioning problems. If I want to update one library, I may have to update several of it's dependant libraries, ad nauseum. I already deal with this hassle with the rapidly changing XML libraries and the fact that some idiot library developers insist on including dated versions of the dom and sax api's in their jars. /rant People need to realize that there are lots of legacy users out there who aren't limited by only 'harddrive space'. - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[OT] Re: [Math] common-math and bloated 3rd party libraries
--- Phil Steitz [EMAIL PROTECTED] wrote: David Graham wrote: --- Charles Hudak [EMAIL PROTECTED] wrote: Mark wrote: 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! I think that this comment is a little shortsighted. We are still using weblogic 5.1 and constantly have problems with the multitude of third party libraries that we are using. WL 5.1 does not seem to find libraries in the WEB-INF/lib directory, as it should, so these have to be set using the classpath. Unfortunately, on Windows NT, the commandline has a size limitation. Every so often, after adding another library, we are unable to start the server due to a the command is too long error. This is a PITA and we have been working around it for several years. Having to add 3 or 4 extra commons jars just because I want to use ONE of the libraries is lame. I agree that packages should limit dependencies and I sympathize with your problems. However, you're using a broken container on a lame desktop OS. Trying to work around issues like this is *way* out of scope for commons packages. I agree with your assessment of that platform; but your comment raises an interesting question: to what extent should commons component design decisions be influenced by characteristics of the user base. My opinion is lots. Struts has a perfect example of why this is a bad idea. At one point we changed our META-INF/Manifest.mf file from the standard format to a format that WebLogic 5 would accept. Sometime later, another bug was filed because Tomcat didn't like our new Manifest.mf file format because it wasn't in the standard format. Straying from standard practices to accomodate broken products in your user base is a quick way to generate a lot of bug reports. IMO, the Windows line length limitation and WebLogic's broken jar lookup are absolutely not reasons to change Jakarta Commons components. David Lame and broken as it may be, WebLogic 5 on NT has a large installed base = lots of potential commons users. Similarly, WebSphere 3 (JDK - sic - 1.2.2) and WebSphere 4 (JDK 1.3.1) are huge. Most of these folks have do not have the luxury of choosing their deployment targets and they often have limited control over their deployment environments. I think that it is very reasonable to try to make things as easy as possible for them. I also agree with Danny's observation above that for commons-math in particular, the commitment in the proposal was to keep dependencies to a minimum. Phil David I'm all for code reuse but it seems as if the commons developers have created alot of unnecessary dependancies between the projects (maybe as a show of solidarity, who knows). This also creates versioning problems. If I want to update one library, I may have to update several of it's dependant libraries, ad nauseum. I already deal with this hassle with the rapidly changing XML libraries and the fact that some idiot library developers insist on including dated versions of the dom and sax api's in their jars. /rant People need to realize that there are lots of legacy users out there who aren't limited by only 'harddrive space'. - 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] - 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]
Re: [Math] common-math and bloated 3rd party libraries
Phil Steitz wrote: I agree with your assessment of that platform; but your comment raises an interesting question: to what extent should commons component design decisions be influenced by characteristics of the user base. My opinion is lots. Lame and broken as it may be, WebLogic 5 on NT has a large installed base = lots of potential commons users. Similarly, WebSphere 3 (JDK - sic - 1.2.2) and WebSphere 4 (JDK 1.3.1) are huge. Most of these folks have do not have the luxury of choosing their deployment targets and they often have limited control over their deployment environments. I think that it is very reasonable to try to make things as easy as possible for them. I also agree with Danny's observation above that for commons-math in particular, the commitment in the proposal was to keep dependencies to a minimum. Phil Certainly not arguing about decisions influenced by characteristics of the user base. We definitly want this. And I think expecially in the consideration of JVM versions and capabilities, But, you know, wow what a murky and subjective domain when you get into web-platforms. And to be a bit more philisophical, Literally, by maintaining for an older platform, you promote continued usage of that platform, which contributes to more issues you need to balance out across versions of platforms. Eventually there needs to be a line drawn I really hope we don't think the command line limitations of the Windows platform should be an issue in deciding how many jars we're going to make the math project dependent on. lol 8-) -M. p.s. Yes, I'm the one eating my words by dragging this subject on even further now after I said to get back to the matter of dependencies in math specifically ;-) -- Mark Diggory Software Developer Harvard MIT Data Center http://osprey.hmdc.harvard.edu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
