MrBean: Correct handling of re-abstracted methods

[robbytx]

This builds on #109 to verify and fix the behavior of checking re-abstracted methods for concreteness.

Problem

When searching for a concrete override, the existing logic will skip over methods in subclasses that are marked abstract. If such a method is an override for a concrete method in a parent class, then the logic will incorrectly search the parent class where it will find the concrete method and it will incorrectly return true from hasConcreteOverride.

This behavior has the following undesirable outcomes, depending on the FAIL_ON_UNMATERIALIZED_METHOD setting:

1. When disabled, then subsequent invocation of the re-abstracted method will throw an AbstractMethodError, rather than an UnsupportedOperationException.
2. When enabled, then the re-abstracted method will incorrectly NOT fail during materialization.

Solution

Once we locate the matching method, we can simply return whether that method is concrete.

This works because our search process always locates the most-specific method:

• If the method is public, then it is guaranteed to be returned by getMethod.
• If the method is non-public, then our search process starts at the implemented type, and traverses linearly up the class hierarchy.
• Also, it is not possible for a public method to be overridden by a non-public method.

Verification

I've added unit tests to cover each of the cases:

• Reabstracted method from java.lang.Object
• Reabstracted bean property method
• Reabstracted public custom method
• Reabstracted non-public custom method

[cowtowncoder]

Excellent, thank you again!