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 librarie
Date Fri, 07 Nov 2003 23:01:47 GMT
 > Mark:
 >
 > What is your plan for the BeanTransformer.transform() method regarding
 > logging/exception throwing? (in particular as to how the current junit
 > test is executing)
 >

Right now my implementations of the NumberTransformer look like this:

public interface NumberTransformer {
     double transform(Object o) throws MathException;
}

Default Transformer simply looks like this

public class DefaultTransformer implements NumberTransformer {

     public double transform(Object o) throws MathException{

	if (o == null) {
		throw new MathException(
		"Conversion Exception in Transformation," +
		" Object is null");
	}

	if (o instanceof Number) {
		return ((Number)o).doubleValue();
	}

	try {
		return new Double(o.toString()).doubleValue();
	} catch (Exception e) {
		throw new MathException(
		"Conversion Exception in Transformation: " +
		e.getMessage(),
		e);
	}
     }
}

I actually made BeanTransformer an annonymous class in BeanListUnivariate

public void setPropertyName(String propertyName) {
    this.propertyName = propertyName;
    this.transformer = new NumberTransformer() {
	public double transform(final Object o) throws MathException {
	   try {
		return (
			(Number) PropertyUtils.getProperty(
				o,
				getPropertyName())).doubleValue();
	   } catch (IllegalAccessException e) {
		throw new MathException(
			"IllegalAccessException in Transformation: " +
			e.getMessage(),
			e);
	   } catch (InvocationTargetException e) {
		throw new MathException(
			"InvocationTargetException in Transformation: "+
			e.getMessage(),
			e);
	   } catch (NoSuchMethodException e) {
		throw new MathException(
			"oSuchMethodException in Transformation: "+
			e.getMessage(),
			e);
	   }
	}};
    }

I then just moved this implementation into the test directory for now. 
If having this as an annonymous inner class is problematic we can put it 
back outside.

Since we are really relying on the performance of bean-utils in this 
case, all we're testing is the behavior of PropertyUtils from the 
Bean-utils project, which makes me wonder if the JUnit test is really 
useful as any problems would really be arising in bean-utils code, not 
math. I personally think much of the testing going on in 
BeanTransformerTest should really be going on in BeanListUnivarateImplTest

-Mark

Matt Cliff wrote:


> On Thu, 6 Nov 2003, Mark R. Diggory wrote:
> 
> 
>>Brent,
>>
>>I've been experimenting with some refactoring that removes 100% of our 
>>dependencies on bean-utils, The first usage was BeanTransformer, the 
>>second usage was in DefaultTransformer. I rewrote DefaultTransformer to 
>>not need bean-utils with only a few extra lines of code, I expect it is 
>>also a bit more efficient because of the removal of extra method calls 
>>to been-utils. I'm attempting to do this with BeanTransformer (but its a 
>>bit more challenging as its using some bean introspection instead of 
>>just attempting to turn the object into a double).
>>
>>Logging is only in a few places outside of this, I think I can remove 
>>this runtime dependency. So in my book I think we reasonably accomplish 
>>trimming down the runtime dependencies to the following
>>
>>commons-discovery
>>commons-collections
>>commons-lang
>>
>>And trim the compile time dependencies down to
>>
>>commons-discovery
>>commons-collections
>>commons-lang
>>commons-logging
>>
>>Does this sound at all reasonable?
>>
>>-Mark
>>
>>brent@worden.org wrote:
>>
>>>commons-logging:
>>>
>>>A little more investigation revels, commons-beanutils depends on
>>>commons-logging.  Hence, the only way to remove commons-math's
>>>dependency on commons-logging, is to remove commons-math's dependency
>>>on commons-beanutils.  So, as long as commons-math is dependent on
>>>commons-beanutils, nothing is gained, in terms of bloat, by removing
>>>the commons-logging dependency.
>>>
>>>My stance is to use commons-logging.
>>>
>>>
>>>commons-discovery:
>>>
>>>Since I added the discovery stuff I will be its advocate.  One of the
>>>visions for commons-math is to create a kind of service provider API
>>>for math routines and break commons-math into two logical parts: the
>>>SPI and the default implementation.  Then, commons-math would either
>>>invite other service providers (Mathematica, MatLab, S-Plus, ...) to
>>>create adaptors or we would develop them.  The route we have chosen to
>>>enable the SPI is via the abstract factories.  To instantiate concrete
>>>factory instances, I decided to use the features provided by
>>>commons-discovery.  Prior to its injection, the concrete factories
>>>used system properties for instantiation.  This is limiting in the
>>>sense only one service provider can be used per JVM and in a app
>>>server type deployment, there may be a need to have utilize many
>>>different service provides for different applications.  With
>>>commons-discovery, the system property approach is still supported
>>>along with properties files and the Jar SPI specification.  The later
>>>two would enable the possibility of have multiple service providers
>>>under one JVM.  Thus, using commons-disovery nothing is lost over the
>>>original implementation and some nice flexibility is gained.
>>>
>>>My stance is to use commons-discovery.
>>>
>>>commons-collections:
>>>commons-lang:
>>>commons-beanutils:
>>>
>>>No one seems to be objecting to these much so won't bother defending
>>>our reasons for using them.
>>>
>>>
>>>Here's a thought.  One thing we might do to limit the proliferation of
>>>jars is to create a jar containing commons-math as all of its
>>>dependencies.  Maven has an uberjar plugin that might be the ticket to
>>>creating such a jar.  There ares risk with deploying such a jar as
>>>there might be version conflicts if other versions of the dependencies
>>>are deployed separately.  I'm not a big advocate of this strategy
>>>(I've had to many struggles working with products that came bundled
>>>with old version of xerces) but it might be to quell some of the
>>>dependency backlash.
>>>
>>>Brent Worden
>>>http://www.brent.worden.org/
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>>>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>>
>>
>>
> 

-- 
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