commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Cooper" <martin.coo...@tumbleweed.com>
Subject RE: [lang] Reflection utils [was: 1.0 release foci]
Date Wed, 14 Aug 2002 17:24:15 GMT


> -----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]

+1

> 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)

+1

> 3) One class or many?
> Either 
> ReflectionUtils
> or 
> ClassUtils, FieldUtils, ConstructorUtils & MethodUtils

My preference would be multiple (but not many :) classes, probably in their
own package. The class names you list above sound fine.

> 
> 4) Exception handling?
> Do we throw the Sun exceptions directly, or do we wrap all 
> the Sun exceptions in a single ReflectionException (using 
> NestedException).

+1 for a single ReflectionException extending 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.

+1. No point in reinventing the wheel.

--
Martin Cooper


> 
> 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