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.
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
Suppress false positives by adding the suppression annotation
@SuppressWarnings("MethodCanBeStatic") to the enclosing element.