commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jack, Paul" <pj...@sfaf.org>
Subject RE: [lang] Reflection utils [was: 1.0 release foci]
Date Wed, 14 Aug 2002 16:50:52 GMT
I agree with Steve's four-point list, and like separate classes in their
own subpackage for organization.

However, I'm a little confused by Henri's list of methods below.  They
don't seem to add any functionality to the existing reflection APIs
other than, perhaps, exception handling.  Is that the point (I do
agree that catching the myriad of reflection exception is commonly
a pain) or do they do more?

-Paul

> -----Original Message-----
> From: scolebourne@btopenworld.com [mailto:scolebourne@btopenworld.com]
> Sent: Wednesday, August 14, 2002 2:07 AM
> To: commons-dev@jakarta.apache.org; ola.berg@arkitema.se
> Subject: [lang] Reflection utils [was: 1.0 release foci]
> 
> 
> Before we start on reflection in lang, we need to agree some 
> basic things. Here's my list.
> 
> 1) No code that implies beans.
> That is in [beanutils]
> 
> 2) Only static utilty classes.
> This fits with [lang] and creates less issues.
> This excludes Ola's code below, but that should be destined 
> for [introspect] (a new project to replace Sun's bean Introspector)
> 
> 3) One class or many?
> Either 
> ReflectionUtils
> or 
> ClassUtils, FieldUtils, ConstructorUtils & MethodUtils
> 
> 4) Exception handling?
> Do we throw the Sun exceptions directly, or do we wrap all 
> the Sun exceptions in a single ReflectionException (using 
> NestedException).
> 
> 
> These strike me as the basics that need agreement before we 
> start. The code itself should draw on code previously written 
> by [beanutils], [jxpath], and others.
> 
> Stephen
> 
> >  from:    Ola Berg <ola.berg@arkitema.se>
> > Hen writes:
> > >I\'ve pushed the ClassUtils class back into the Lang cvs tree for
> > >consideration. Methods are:
> > 
> > >    public static java.lang.Object createObject(java.lang.String);
> > >    public static java.lang.Object createObject(java.lang.Class);
> > >    public static boolean classExists(java.lang.String);
> > >    public static java.lang.Class getClass(java.lang.String);
> > >    public static boolean classInstanceOf(java.lang.Class, 
> java.lang.String);
> > >    public static boolean classImplements(java.lang.Class, 
> java.lang.String);
> > >    public static boolean classExtends(java.lang.Class, 
> java.lang.String);	
> > 
> > In a bunch of code I gave Stephen, the questions answered 
> in the boolean methods of your interface are implemented as 
> separate Predicate\'s. General util classes for Class, 
> Method, Field, Member etc can take such Predicates and filter 
> out the relevant. So one can create a Predicate that 
> evaluate()s to true for \"class whose name begins with Foo 
> that is somewhere in the org.apache structure that implements 
> Bazilizable and has a protected static method with three 
> parameters\" or anything.
> > 
> > This semi-architecture was intended to go in some kind of 
> [reflect] package. If [lang] should do ClassUtils and 
> FileUtils kind of stuff, as in your interface, i suggest that 
> the predicate based architecture goes into lang. 
> > 
> > (Or thinking about it, in the block I sent to Stephen, the 
> Class predicates was not implemented. But they should work in 
> this way)
> > 
> > /O
> > 
> > --------------------
> > ola.berg@arkitema.se
> > 0733 - 99 99 17
> > 
> > --
> > To unsubscribe, e-mail:   
<mailto:commons-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
<mailto:commons-dev-help@jakarta.apache.org>
> 


--
To unsubscribe, e-mail:
<mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail:
<mailto:commons-dev-help@jakarta.apache.org>

--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message