> > I worked around this by testing whether > mth.equals(cls.getMethod(mth.getName(), mth.getParameterTypes())). This > seems to expose another bug because on numerous occasions I get a > NoSuchMethodException from this check, which shouldn't ever be > possible... the imaginary conversation between my code and the class > goes something like this: > > me: Hi, what methods do you support? > class: I support a method called foo with parameter types {bar, baz}. > me: Okay, give me the method called foo with parameter types {bar, baz}. > class: I have no such method! > > I'll see if I can produce a simplified test case for both these bugs. For the second bug, that would be nice. I checked in a fix for the first problem (reporting overridden methods twice.) Update libraries/clib/native/Class.c - Godmar
- Another reflection bug; compatibility results Stuart Ballard
- Re: Another reflection bug; compatibility results Edouard G. Parmelan
- Re: Another reflection bug; compatibility results Stuart Ballard
- Re: Another reflection bug; compatibility results Edouard G. Parmelan
- Re: Another reflection bug; compatibility results Stuart Ballard
- Re: Another reflection bug; compatibility results Artur Biesiadowski
- Re: Another reflection bug; compatibility results Stuart Ballard
- Re: Another reflection bug; compatibility results Godmar Back
- Re: Another reflection bug; compatibility results Godmar Back
- Re: Another reflection bug; compatibility results Stuart Ballard
- Re: Another reflection bug; compatibility res... Edouard G. Parmelan
- Re: Another reflection bug; compatibility results Stuart Ballard
- Re: Another reflection bug; compatibility res... Godmar Back
- Re: Another reflection bug; compatibility results Godmar Back
- Re: Another reflection bug; compatibility results Godmar Back
- Re: Another reflection bug; compatibility results Stuart Ballard
- Re: Another reflection bug; compatibility res... Godmar Back
- Re: Another reflection bug; compatibility results Stuart Ballard