Fix assertions being generated for bridge methods instead of actual getter method

[instantapfel]

Problem

When generating assertions for getter methods, the AssertJ generator creates a single GetterDescription per getter name. The description is currently derived from the first method returned by Class#getMethods() or Class#getDeclaredMethods().

In most cases this works as expected. However, it becomes problematic for classes that contain compiler-generated bridge methods, for example:

private static abstract class AbstractClassWithGeneric<T> {
  public abstract T getValue();
}

private static class ConcreteClass extends AbstractClassWithGeneric<String> {
  @Override
  public String getValue() {
    return null;
  }
}

For ConcreteClass, the compiler generates two methods named getValue():

• String getValue() (the actual implementation)
• Object getValue() (a synthetic bridge method)

The Java Reflection API does not guarantee the order of methods returned by Class#getDeclaredMethods() or Class#getMethods(). As a result, the generator may pick either method when building the GetterDescription.

This can lead to non-deterministic output, generating either hasValue(String value) or hasValue(Object value) depending on the method order returned at runtime. Consequently, the generated assertion files may change between executions of the generator even when the source code itself has not changed.

Solution

This PR excludes bridge methods when collecting getter descriptions. This ensures that the generator consistently uses the actual getter implementation and produces deterministic assertion methods.