Alternate names: static-method
Consider an instance method that is not an override, is not overrideable itself,
and never accesses this (explicitly or implicitly) in its implementation. Such a
method can always be marked static without harm.
The main benefit of adding static is that a caller who wants to use the method
and doesn’t already have an instance handy won’t have to conjure one up
unnecessarily. Doing that is a pain, and in unit tests it also creates the false
impression that instances in multiple states need to be tested.
But adding static also benefits your implementation in some ways. It becomes a
little easier to read and to reason about, since you don’t need to wonder how it
might be interacting with instance state. And auto-completion will stop
suggesting the names of instance fields and methods (which you probably don’t
want to use).
This analogy might work for you: it’s widely accepted that a method like this
shouldn’t declare any parameters it doesn’t actually use; such parameters should
normally be removed. This situation with static is fairly similar: in either
case there is one additional instance the caller needs to have in order to
access the method. So, adding static is conceptually similar to removing that
unused parameter.
Suppress false positives by adding the suppression annotation @SuppressWarnings("MethodCanBeStatic") to the enclosing element.