Ignoring synthetic/bridge methods

[Rich Hickey]

How is everyone handling the filtering of synthetic/bridge methods?

Using the reflection API, I'm seeing differences between JDK 1.5 and
6, with methods like StringBuilder.length marked as bridge/synthetic
in JDK 6 (!?)

Is there a reliable way to deduce the 'real' method set via
reflection?

Here are the signatures and (hex) modifiers for StringBuilder, via
getMethods():

http://clojure.googlegroups.com/web/jdk5.txt
http://clojure.googlegroups.com/web/jdk6.txt

In JDK 1.5, filtering on isBridge works ok. But this will filter out
StringBuilder.length and others on JDK 6.

Thanks for any ideas,

Rich

[Attila Szegedi]

Most interesting, especially considering that bridge methods are
really only ever needed for parametric types, and there's not a single
type parameter in StringBuilder...

Well, according to your pages, the length() method itself has 1041 for
modifier in , which is 1024+16+1, which, according to <http://java.sun.com/javase/6/docs/api/constant-values.html#java.lang.reflect.Modifier.PUBLIC
> means ABSTRACT+FINAL+PUBLIC. I guess they're using the otherwise
nonsensical ABSTRACT+FINAL combo to denote a bridge? (I honestly don't
know). If so, then even Java 5 StringBuilder has a suspiciously large
number of these... i.e. doppelgangers of normal insert() and append()
methods returning java.lang.AbstractStringBuilder (a class I otherwise
didn't hear of). I find that too quite strange.

> Thanks for any ideas,

Well, can't say I have any at the moment... I'm thoroughly puzzled
myself.

Attila.

[Patrick Wright]

Maybe you could post a question to the Javac-dev mailing list?
http://mail.openjdk.java.net/mailman/listinfo/compiler-dev

[Jeroen Frijters]

Attila Szegedi wrote:
> On Sep 16, 2008, at 3:15 AM, Rich Hickey wrote:
> >
> > How is everyone handling the filtering of synthetic/bridge methods?
> >

[...]

>
> Most interesting, especially considering that bridge methods are really
> only ever needed for parametric types, and there's not a single type
> parameter in StringBuilder...

I think that in this case the bridge is inserted because AbstractStringBuilder isn't public.

I'm still trying to figure out how to recognize these methods... On (not very appealing) idea is to look at the target method that the bridge is calling, if it has the same signature you can probably assume that it is an "access" bridge (in contrast with a "variance" bridge).

BTW, I'm incredibly tempted to name these two types of bridges Beau and Jeff :-)

Regards,
Jeroen

[Rémi Forax]

Attila Szegedi a écrit :

> On Sep 16, 2008, at 3:15 AM, Rich Hickey wrote:
>
>
>> How is everyone handling the filtering of synthetic/bridge methods?
>>
>> Using the reflection API, I'm seeing differences between JDK 1.5 and
>> 6, with methods like StringBuilder.length marked as bridge/synthetic
>> in JDK 6 (!?)
>>
>> Is there a reliable way to deduce the 'real' method set via
>> reflection?
>>
>> Here are the signatures and (hex) modifiers for StringBuilder, via
>> getMethods():
>>
>> http://clojure.googlegroups.com/web/jdk5.txt
>> http://clojure.googlegroups.com/web/jdk6.txt
>>
>> In JDK 1.5, filtering on isBridge works ok. But this will filter out
>> StringBuilder.length and others on JDK 6.
>>
>
> Most interesting, especially considering that bridge methods are
> really only ever needed for parametric types, and there's not a single
> type parameter in StringBuilder...
>

Don't forget covariant return type :)

> Well, according to your pages, the length() method itself has 1041 for
> modifier in , which is 1024+16+1, which, according to <http://java.sun.com/javase/6/docs/api/constant-values.html#java.lang.reflect.Modifier.PUBLIC
> > means ABSTRACT+FINAL+PUBLIC. I guess they're using the otherwise
> nonsensical ABSTRACT+FINAL combo to denote a bridge? (I honestly don't
> know).

see jsr202, you can download the jvms spec update, the doc
ClassFile-Java6.pdf, page 123:
ACC_BRIDGE 0x0040
ACC_SYNTHETIC 0x1000

> If so, then even Java 5 StringBuilder has a suspiciously large
> number of these... i.e. doppelgangers of normal insert() and append()
> methods returning java.lang.AbstractStringBuilder (a class I otherwise
> didn't hear of). I find that too quite strange.
>

Rémi

[Attila Szegedi]

On Sep 16, 2008, at 12:41 PM, Rémi Forax wrote:

> Attila Szegedi a écrit :
>> On Sep 16, 2008, at 3:15 AM, Rich Hickey wrote:
>>
>>
>>> How is everyone handling the filtering of synthetic/bridge methods?
>>>
>>> Using the reflection API, I'm seeing differences between JDK 1.5 and
>>> 6, with methods like StringBuilder.length marked as bridge/synthetic
>>> in JDK 6 (!?)
>>>
>>> Is there a reliable way to deduce the 'real' method set via
>>> reflection?
>>>
>>> Here are the signatures and (hex) modifiers for StringBuilder, via
>>> getMethods():
>>>
>>> http://clojure.googlegroups.com/web/jdk5.txt
>>> http://clojure.googlegroups.com/web/jdk6.txt
>>>
>>> In JDK 1.5, filtering on isBridge works ok. But this will filter out
>>> StringBuilder.length and others on JDK 6.
>>>
>>
>> Most interesting, especially considering that bridge methods are
>> really only ever needed for parametric types, and there's not a
>> single
>> type parameter in StringBuilder...
>>
> Don't forget covariant return type :)

Right. Neither explains why are length() and setLength() marked with
1041 in Java 6 though...

FWIW, I'm quite wary of the overloads that only differ in return
type... Quite recently a bug has come up in my reflection handling
code in FreeMarker regarding covariant bridge methods popping up in
java.beans.PropertyDescriptor instances, see <http://thread.gmane.org/gmane.comp.web.freemarker.devel/6935
>. Basically, the Beans introspector created property descriptors
pairing in them a non-bridge setter and a bridge getter... I also
started some follow up discussion on ADVANCED-JAVA list at <http://discuss.develop.com/archives/wa.exe?A2=ind0808&L=advanced-java&T=0&F=&S=&P=47
> centering on the issue of how do multiple methods that only differ
in return type not screw up the overloaded method resolution algorithm
in JLS 15.2.2... and I didn't get a satisfying answer there.

Attila.

[Rich Hickey]

On Sep 16, 5:08 am, Jeroen Frijters <jer...@sumatra.nl> wrote:
> Attila Szegedi wrote:
> > On Sep 16, 2008, at 3:15 AM, Rich Hickey wrote:
>
> > > How is everyone handling the filtering of synthetic/bridge methods?
>
> [...]
>
> > Most interesting, especially considering that bridge methods are really
> > only ever needed for parametric types, and there's not a single type
> > parameter in StringBuilder...
>
> I think that in this case the bridge is inserted because AbstractStringBuilder isn't public.
>
> I'm still trying to figure out how to recognize these methods... On (not very appealing) idea is to look at the target method that the bridge is calling, if it has the same signature you can probably assume that it is an "access" bridge (in contrast with a "variance" bridge).

Do you mean by bytecode inspection? I guess that would mean a
resounding 'no' to:

>>> Is there a reliable way to deduce the 'real' method set via reflection?

Rich

[Jeroen Frijters]

I'm pretty sure at this point that this is the case (unfortunately). I've settled on using the bytecode inspection approach. BTW, thanks for pointing out this issue, I had missed it.

Regards,
Jeroen