Implicit conversion should avoid `@Deprecated` methods

[jodastephen]

Implicit conversion fallback allows JUnit to convert a String to an arbitrary Object. It does this by searching for a constructor or factory method taking one String (with a further fallback to look for CharSequence added later).

This approach recently caused a problem for me. In a piece of shared code there was a factory method named parseString which I wanted to rename to the more standard parse. I did this by copying the method and marking parseString as deprecated (for removal). I didn't expect this to cause any issues, as it is a standard approach to refactoring a change like this from a shared code library. In the downstream code, someone was using the type via JUnit implicit argument conversion, and the test failed because JUnit now saw the class had 2 static factory methods where previously there was 1.

I'd like to propose a tweak to the algorithm.

1. Find all factory methods with a single String parameter, if there is only one, then use it
2. Find all factory methods with a single CharSequence parameter, if there is only one, then use it
3. (new step) Repeat step 1, removing any method marked as deprecated, if only one method then use it
4. (new step) Repeat step 2, removing any method marked as deprecated, if only one method then use it.

I believe this approach is backwards compatible, and would be a good enhancement. Thanks for your consideration.

[marcphilipp]

Team decision: Implement the above proposal.

@jodastephen Would you be interested in submitting a PR?

[jodastephen]

Thanks for approving. I'm currently maxed out with conference prep and day job, but may be able to get to it in a few weeks.