A private method that does not reference the enclosing instance can be static


Alternate names: static-method

The problem

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.


Methods which are used by reflection can be annotated with @Keep to suppress the warning.

The @Keep annotation can also be applied to annotations, to suppress the warning for any member annotated with that annotation.


@interface SomeAnnotation {}

public class Data {
  int doSomething(int x) {
    return x;

All false positives can be suppressed by annotating the variable with @SuppressWarnings("MethodCanBeStatic").