On Wed, 4 Dec 2002, Rodney Waldhoff wrote:
> Date: Wed, 4 Dec 2002 13:54:59 -0800 (PST)
> From: Rodney Waldhoff <[EMAIL PROTECTED]>
> Reply-To: Jakarta Commons Developers List <[EMAIL PROTECTED]>
> To: Jakarta Commons Developers List <[EMAIL PROTECTED]>
> Subject: Re: [beanutils] ConstructorUtils in beanutils: a bad idea
>
> 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.
>
Rodney,
You might have missed some earlier conversations on this general topic.
The conclusion was that, ultimately, the MethodUtils class would migrate
from [beanutils] to either [lang] or [reflect], and be complemented there
by ConstructorUtils and other similar goodies. The reasoning was that
MethodUtils was generally useful for calling methods other than beans, and
there were some very tricky workarounds for JDK introspector bugs -- we
wanted people who needed to reflectively call methods not to have to go
through the same pain.
Ultimately, it looks like the decision was to move MethodUtils to [lang],
and ultimately [beanutils] could deprecate our copy and declare a
dependency. If that's still the plan (which I guess it is), we should put
ConstructorUtils where it will end up, rather than here and moving it.
> 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>
>
There's no doubt that ConstructorUtils would be useful -- and there's even
an enhancement request against beanutils to add it. Given the advent of
[lang], though, I think it would make sense for [beanutils] to refine its
focus a little on things that are specifically JavaBeans related (the
property accessor stuff today, maybe some frameworks for event listeners
and such later?).
>
> 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.
>
There's circa 100 messages in the COMMONS-DEV archives on just this topic
if you'd care to read them :-).
> - Rod
>
Craig
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
