commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <>
Subject Re: [Reflect] Summary of points and relationship with BeanUtils
Date Thu, 20 Jun 2002 03:13:24 GMT

On Wed, 19 Jun 2002, Stephen Colebourne wrote:

> Date: Wed, 19 Jun 2002 21:54:34 +0100
> From: Stephen Colebourne <>
> Reply-To: Jakarta Commons Developers List <>
> To: Jakarta Commons Developers List <>
> Subject: Re: [Reflect] Summary of points and relationship with BeanUtils
> From: "Michael A. Smith" <>
> > I haven't followed this thread too closely, but I'm not sure where the
> > chicken and egg are.  Rather than *moving* the code to lang, you can
> > *copy* it.  Then, BeanUtils or whatever can still depend on its own
> > version until the lang version is released.  Then, BeanUtils can update
> > (when they're ready) to use the new version that exists in the released
> > version of lang, assuming, of course, that the version in lang is as
> > good, or better, than the version already in BeanUtils.
> Actually, this is what I'm arguing for ;)
> > btw, I'd prefer if this reflection stuff was in a package other than
> > lang.  When I think of the "lang" package, I think of stuff like
> > "Strings", "Integers", etc.  "Predicate" "Closure" and "Factory"
> > probably apply there as well.  Essentially, the most basic of basic
> > coding stuff that just plainly doesn't exist in the java APIs.  Any type
> > of layer over reflection/introspection is a layer above what I view
> > "lang" to be
> What I am proposing for Lang is one class, with methods to assist with
> *reflection*, not introspection. Example methods
> - getAllSuperInterfaces(Class)
> - getAllSuperClasses(Class)
> - getAllMethods(Class)
> - getAllFields(Class)
> - getMethodSignature(Method)
> - getMethodPolymorphically(Class, Object[])
> - getClassName(Class)
> - getPackageName(Class)
> There will be no reference to beans, or the Introspector class, or
> introspection in general. The class' purpose is methods to assist with the
> java.lang.reflect package. ie. to provide methods that are missing in Java.
> Hence Lang.

There's an existing enhancement request against BeanUtils (in Bugzilla) to
create a ConstructorUtils analog to the things in MethodUtils -- and there
is probably some common code that could be factored out between the two,
so I'd bet we're talking more like three classes than one.

In addition, many of the signatures above seem like *very* low value-add
over the standard Java APIs -- the most complicated things (looking up the
right Method object by scanning all the superclasses and implemented
interfaces/superinterfaces is the important part.  Everything else looks
like syntactic sugar over existing JDK capabiities.

> Stephen


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message