PreferJavaTimeOverload fails on AssertJ extensions which handle time

[carterkozak]

Description of the problem / feature request:

PreferJavaTimeOverload fails eroniously on assertj assertion classes which have time overloads, or extend org.assertj.core.api.Assertions.

Feature requests: what underlying problem are you trying to solve with this feature?

Consider allowing methods named assertThat which return subtypes of org.assertj.core.api.Assert to pass validation rather than whitelisting only org.assertj.core.api.Assertions.assertThat

Bugs: what's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

Easiest way to reproduce this is by subclassing Assertions (nonfinal utility class, obviously it's bad practice to extend static utility classes in modern java, but this occurs relatively frequently in the wild).

What version of Error Prone are you using?

2.3.4

Have you found anything relevant by searching the web?

no.

[Stephan202]

Relates to #1377; sounds like a subtype-aware variation on f1df86d will fix this.

[php-coder]

Easiest way to reproduce this is by subclassing Assertions (nonfinal utility class, obviously it's bad practice to extend static utility classes in modern java, but this occurs relatively frequently in the wild).

In my case, a test implements WithAssertions that also fired this check but it doesn't seem a bad practice.

[kluever]

I think this can be closed now. Please re-open if you'd like additional opt-out heuristics