Hi Bene,
> Hi,
>
> while working on BU2, I was thinking about the API and what may be improved.
>
great! :)
> Exceptions:
> Right now a lot of API methods just populate the checked reflection
> exceptions like InvocationTargetException from the native java
> reflection API. This dooms Java 6 users to write code like:
>
> try {
> Bean clone = on( original ).cloneBean();
> } catch (IllegalAccessException iae) {
> // what to do here?
> } catch (InstantiationException ie) {
> // and here?
> } catch (IntrospectionException ie2) {
> // and here?
> } catch (InvocationTargetException ite) {
> // and here?
> } catch (NoSuchMethodException nsme) {
> // and here?
> }
>
right, this is more a matter of history than pure technical reasons:
when setting-up BU2, I started "cloning" from his big brother BU - of
course there are rooms of improvements, and this is one of them
> The missing javaDoc for some exceptions shows, that I myself was
> unsure in what cases some exceptions will occure.
> To overcome this, users may implement something like:
>
> try {
> Bean clone on( original ).cloneBean();
> } catch (Exception e) {
> // now nothing can go wrong, right?
> }
>
> The problem is, that this will swallow useful RuntimeExeptions (for
> example like IllegalArgumentException when passing null to a primtive
> property).
I am confused - why RE are swallowed?
> I see several solutions:
> 1. update BU2 to Java 7. We could make use of
> ReflectiveOperationException [1]. Beside that users can use the new
> multi catch blocks.
-1 IMHO the adoption of Java7 won't be immediate - companies won't
switch immediately to the new released JDK we should keep an
acceptable level of backward compatibility - and JDK6 is a good
compromise.
> 2. Wrap checked exceptions into RuntimeExceptions. The question is,
> what a user can do to recover from one of those exceptions. Only if
> there is something the user can do, it would make sense to throw a
> checked exception.
this is currently the option I'd prefer!
> 3. leave everything as is
>
> All tree solution have pros and cons. I think that having a method
> like cloneBean() throw 5 checked exceptions feels rather clumsy. So I
> prefer the second option. What do you think?
see above :P
>
> Processing of Annotations:
> Do we have access of annotations on our agenda? I can imagine something like:
>
> on ( bean.getClass() ).getAnnotation( "annotationName" ).fromMethod(
> "methodName" ).getValue( "valueName" );
>
> The exact API would have to be discussed. But in general, I think this
> fits nicely into BU2.
>
I see Annotations processing could fit the "agenda" (I see the need
now for a wiki page to track ideas) - not sure what is the added value
of having this kind of proposed APIs - I'd postpone that feature
anyway to once all (more or less, we will discuss about it) old BU
features are supported.
To see what I had in mind to simplify the Annotations processing, have
a look at the prototype in 'classvisitor'[1] subpackage in the Meiyo
Sandbox component - have a look also at a testcase[2].
Keep in mind that is just a prototype, I prefer not discussing about
it in this thread ;)
> Changing of MappedProperty(Getter|Setter)Accessor:
> A while ago we decided to shorten method names as much as possible.
> For example we changed BeanAccessor.getProperty(String propertyName)
> to BeanAccessor.get(String propertyName). However, we did not change
> the methods on MappedProperty(Getter|Setter)Accessor and
> ArgumentsAccessor, all three classes define "withXXX" as methods.
>
> How do you feel about changing
> MappedProperty(Getter|Setter)Accessor.withKey(String key)
> to
> MappedProperty(Getter|Setter)Accessor.for(String key)
> so that ArgumentsAccessor.withArguments( Argument... Arguments )
> can be changed to
> ArgumentsAccessor.with( Argument... Arguments )
>
> This would result in a fluent call like:
> on( bean ).getMapped( "mappedProperty" ).for( "theKey" );
> and
> on( bean ).setMapped( "mappedProperty" ).for( "theKey" ).with( value );
> and
> on (bean ).invoke( "methodName" ).with( value1, value2, value3);
Sounds good - I'm now waiting for the patches!!! :P
Best and thanks,
-Simo
[1] http://s.apache.org/classvisitor
[2] http://s.apache.org/AnnotatedClassVisitorTestCase.java
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
