Uncovering Java Reflection’s Hidden Pitfalls: Overloaded Methods and Generic Bridge Bugs

Reflection Meets Method Overloading

When a method is overloaded (e.g., grade(int) and grade(Integer)), developers often assume that reflection will choose the overload based on the runtime argument type. In reality, the method selected by Class.getDeclaredMethod depends on the parameter type you pass to the reflection API . If you pass Integer.TYPE (which represents the primitive int), the reflection call will always resolve to the grade(int) overload, even when you later supply an Integer instance such as Integer.valueOf("36").

To call the Integer overload via reflection, you must specify Integer.class as the parameter type when retrieving the method:

Method m = MyClass.class.getDeclaredMethod("grade", Integer.class);

Using the correct Class object ensures that the intended overload is invoked.

Generic Type Erasure and Bridge Methods

Java generics are implemented through type erasure: the generic type parameter T is replaced with its upper bound (or Object if unbounded) at compile time. Consequently, a generic method like setValue(T value) becomes setValue(Object value) in the bytecode.

If a subclass specifies a concrete type for T (e.g., String), the compiler generates a bridge method to preserve polymorphism. The bridge method has the erased signature ( setValue(Object)) and forwards the call to the type‑specific implementation ( setValue(String)). This bridge method is marked with the synthetic and bridge flags.

When reflection is used to invoke setValue, both the bridge method and the concrete method may appear in the method list returned by Class.getMethods(). If you do not filter out bridge methods, you can end up invoking the method twice, leading to duplicate log entries or other side effects.

To avoid this, retrieve methods with getDeclaredMethods() (which returns only methods declared in the current class) and filter out bridge methods using Method.isBridge():

Method[] methods = clazz.getDeclaredMethods();
for (Method m : methods) {
    if (m.getName().equals("setValue") && !m.isBridge()) {
        // invoke the real implementation
    }
}

Additionally, always annotate overriding methods with @Override. The annotation lets the compiler detect mismatches caused by type erasure, preventing silent failures where a method is not actually overridden.

Practical Fixes

Use getDeclaredMethod with the exact parameter Class (e.g., Integer.class instead of Integer.TYPE) to select the intended overload.

When scanning for methods via reflection, prefer getDeclaredMethods and filter out bridge methods with Method.isBridge().

Annotate overriding methods with @Override to let the compiler catch erasure‑related mismatches.

If duplicate method calls still occur, verify that only one implementation (the concrete one) is being invoked after filtering.

By understanding how reflection resolves method signatures and how generic type erasure introduces bridge methods, developers can avoid subtle bugs such as invoking the wrong overload or unintentionally calling a method twice.