commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Colebourne" <>
Subject Re: [Reflect] Summary of points and relationship with BeanUtils
Date Wed, 19 Jun 2002 20:54:34 GMT
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.


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

View raw message