Extensibility of ProtectedReaderMethodFinder, composability of OrderedMethodCollector and bridge methods

[Donnchadh Ó Donnabháin]

Hi again,

In order to exclude bridge methods from consideration I've created my
own SetterMethodCollector and ReaderMethodFinder .
I've extended ProtectedReaderMethodFinder but this is made slightly
cumbersome by the fact that qualified(Method m, int mod) is package
private rather than protected. It would be nice if this was protected
as I could just override it to exclude bridge methods.

Also it would be nice to have the ability to supply an underlying
SetterMethodCollector to OrderedMethodCollector rather than unly
supporting PublicSetterMethodCollector.

It might be nice to exclude bridge methods by default.

Donnchadh

[Hanson Char]

Thanks for the suggestions. Will look into this.

> It might be nice to exclude bridge methods by default.

By bridge method I suppose you mean any method name that contains "$" ?

Hanson

2011/1/13 Donnchadh Ó Donnabháin <donn...@gmail.com>:

[Hanson Char]

The changes (except the bridge method feature) are now in SVN.

(Feel free to post sample code on how you'd like it to be patched/changed.)

Hanson

[Donnchadh Ó Donnabháin]

The short answer is that I'd like to exclude any Method m where
m.isBridge() == false .

The longer answer is that some of our domain model classes have
getters that return a value of a narrower type than the same getter.
To support this, the Java compiler generates hidden 'bridge' methods,
having the same return type as the overridden method, in the child
class. Sometimes ProtectedReaderMethodFinder will find the bridge
method first and sometimes it will find the correct method first,
eventually resulting in ClassCastExceptions when a setter is called
with an object of the incorrect type.

Hibernate had a similar problem until 3.6.0
http://opensource.atlassian.com/projects/hibernate/browse/HHH-2268 .

Donnchadh

[Donnchadh Ó Donnabháin]

Thanks Hanson, that's great.

This is roughly what I had in mind for the Bridge methods:

class NonBridgeProtectedReaderMethodFinder extends
ProtectedReaderMethodFinder {
boolean qualified(Method m, int mod) {
return (super. qualified(m, mod) && !m.isBridge();
}
}

class NonBridgeSetterMethodCollector implements BeanMethodCollector {
private final BeanMethodCollector setterMethodCollector;

public NonBridgeSetterMethodCollector(BeanMethodCollector
setterMethodCollector) {
this.setterMethodCollector = setterMethodCollector;
}

@Override
public Method[] collect(Object bean) {
List<Method> setters = new ArrayList<Method>();
for (Method method: setterMethodCollector.collect(bean)) {
if (!method.isBridge()) {
setters.add(method);
}
}
return setters.toArray(new Method[setters.size()]);
}

@Override
public String getMethodPrefix() {
return setterMethodCollector.getMethodPrefix();
}
}

Donnchadh

[Hanson Char]

Hi Donnchadh,

I like these two classes, but am unsure whether I should change the
default behavior in Beanlib to skip bridge methods, as doing so would
break backward compatibility. An alternative, of course, would be to
provide an optional flag to control that. Or just leave it as it is,
and the code as is doesn't prevent clients from making customization
such as the examples you give here.

Thanks,
Hanson

2011/1/14 Donnchadh Ó Donnabháin <donn...@gmail.com>: