On Wed, 4 Dec 2002, robert burrell donkin wrote:
>
> i really think that lang is the right place for this [ConstructorUtils].
> are there any good reasons why it needs to be in beanutils?
>
I disagree that ConstructorUtils belongs in lang, or more accurately, I
believe it is a better fit for beanutils.
Why?
1) ConstructorUtils is directly parallel to the existing MethodUtils,
/s/Method/Constructor:
class ConsructorUtils {
Object invokeConstructor(Class klass, Object arg);
Object invokeConstructor(Class klass, Object[] args);
Object invokeConstructor(Class klass, Object[] args, Class[] parameterTypes);
Object invokeExactConstructor(Class klass, Object arg);
Object invokeExactConstructor(Class klass, Object[] args);
Object invokeExactConstructor(Class klass, Object[] args, Class[] parameterTypes);
// [...]
}
class MethodUtils {
Object invokeMethod(Object object, String methodName, Object arg);
Object invokeMethod(Object object, String methodName, Object[] args);
Object invokeMethod(Object object, String methodName, Object[] args, Class[]
parameterTypes);
Object invokeExactMethod(Object object, String methodName, Object arg);
Object invokeExactMethod(Object object, String methodName, Object[] args);
Object invokeExactMethod(Object object, String methodName, Object[] args, Class[]
parameterTypes);
// [...]
}
2) ConstructorUtils fits within the scope of orignal beanutils proposal
rather cleanly:
"The Java language provides Reflection and Introspection APIs (see the
java.lang.reflect and java.beans packages in the JDK Javadocs). However,
these APIs can be quite complex to understand and utilize. The BeanUtils
component provides easy-to-use wrappers around these capabilities."
<http://cvs.apache.org/viewcvs.cgi/*checkout*/jakarta-commons/beanutils/PROPOSAL.html?rev=HEAD&content-type=text/html>
And is likely to be useful for the use cases enumerated withing that
proposal:
"Example use cases include:
* Building scripting languages that interact with the Java object model [...]
* Building template language processors for web presentation and similar uses [...]
* Building custom tag libraries for JSP and XSP environments [...]
* Consuming XML-based configuration resources [...]"
<http://cvs.apache.org/viewcvs.cgi/*checkout*/jakarta-commons/beanutils/PROPOSAL.html?rev=HEAD&content-type=text/html>
The same isn't true for lang:
"This proposal is to create a package of Java utility classes for the
classes that are in java.lang's hierarchy, or are considered to be so
standard as to justify existence in java.lang. The Lang Package also
applies to primitives and arrays."
<http://cvs.apache.org/viewcvs.cgi/*checkout*/jakarta-commons/lang/PROPOSAL.html?rev=HEAD&content-type=text/html>
3) More importantly, beanutils forms a cohesive set of reflection-oriented
and reflection-based classes. The average user of an arbitrary class in
beanutils is significantly more likely to have use for ConstructorUtils
that the average user of lang. Similiarly, the average user of
ConstructorUtils is significantly more likely to have use for other
classes in beanutils than other classes in lang. This is in keeping with
points 1, 2, and 3 of the jakarta-commons charter
<http://jakarta.apache.org/commons/charter.html>
I think one could argue for some sort of commons-reflection package that
contains pieces of beanutils, lang, clazz, etc. (although I'm not sure how
different that would be from the existing beanutils package), but for the
time being I'm pretty sure that's closer to beanutils than to lang.
- Rod
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
