Java Static Members: static Fields and Methods

Belonging to the Class, Not the Object

Most of the fields and methods you have written so far belong to objects: every time you call new, each instance gets its own copy of the fields, and methods run against that specific object's state. The static keyword flips that. A static member belongs to the class itself - there is one copy, shared by every instance, and it exists whether or not you ever create an object.

That single distinction explains static fields, static methods, constants, and even why main is always static.

A Shared static Field

A non-static field gives each object its own slot. A static field gives the class one slot that everybody shares. The classic example is a counter that tracks how many objects have been created:

class User {
    static int count = 0;     // one shared slot for the whole class
    String name;              // one per object

    User(String name) {
        this.name = name;
        count++;              // bump the shared counter on every construction
    }
}

public class Main {
    public static void main(String[] args) {
        new User("Ada");
        new User("Linus");
        new User("Grace");

        System.out.println("users created: " + User.count);
    }
}

Notice you read the counter as User.count - through the class name, because the value does not belong to any one User. Each name, on the other hand, lives inside its own object. Change count through any instance and every instance sees the new value, because there is only one of it.

static Methods

A static method belongs to the class too, so you call it on the class without an object:

class MathUtils {
    static int square(int x) {
        return x * x;
    }

    static int max(int a, int b) {
        return a > b ? a : b;
    }
}

public class Main {
    public static void main(String[] args) {
        System.out.println(MathUtils.square(7));
        System.out.println(MathUtils.max(3, 9));
    }
}

This is exactly the pattern behind the standard library: Math.max, Integer.parseInt, Arrays.sort, and List.of are all static - utility behavior that needs no object to operate on. Reach for a static method when the work depends only on its arguments, not on any per-object state.

The Big Gotcha: static Cannot See instance

A static method runs without any object, so there is no this. That means it cannot touch instance fields or call instance methods directly - there is no specific object to read them from. This is the single most common beginner error with static:

class Account {
    int balance = 100;          // instance field

    static int show() {
        return balance;         // COMPILE ERROR: non-static field 'balance'
    }                           // cannot be referenced from a static context
}

The fix is either to make the method an instance method (drop static, so it has a this), or to pass the object in explicitly:

class Account {
    int balance = 100;

    static int show(Account a) {     // take the object as a parameter
        return a.balance;
    }
}

public class Main {
    public static void main(String[] args) {
        Account a = new Account();
        System.out.println(Account.show(a));
    }
}

The reverse direction is fine: an instance method can freely read static fields and call static methods, because the shared class-level data always exists.

Constants with static final

Combine static with final and you get a constant: one shared value that can never change. By convention these are named in UPPER_SNAKE_CASE:

class Circle {
    static final double PI = 3.14159265;

    double radius;

    Circle(double radius) { this.radius = radius; }

    double area() {
        return PI * radius * radius;   // instance method using a static constant
    }
}

public class Main {
    public static void main(String[] args) {
        System.out.printf("%.2f%n", new Circle(2).area());
    }
}

static final is the idiomatic way to express "a fixed value that belongs to the type" - things like Integer.MAX_VALUE or Math.PI in the standard library. Making it static means you do not waste a copy per object; making it final means nobody can reassign it.

static Initializer Blocks

A simple static field can be initialized inline. When the setup needs real logic - building a lookup table with a HashMap, reading config - use a static block. It runs once, when the class is first loaded, before any object exists:

import java.util.HashMap;
import java.util.Map;

class Roman {
    static final Map<Character, Integer> VALUES = new HashMap<>();

    static {                       // runs once, at class load time
        VALUES.put('I', 1);
        VALUES.put('V', 5);
        VALUES.put('X', 10);
        VALUES.put('L', 50);
    }

    static int valueOf(char c) {
        return VALUES.get(c);
    }
}

public class Main {
    public static void main(String[] args) {
        System.out.println(Roman.valueOf('X') + Roman.valueOf('I'));
    }
}

The block fires a single time no matter how many times you use the class, which makes it the right place for one-time, class-wide setup.

When to Use static

A quick rule of thumb:

• Use a static field only for data that is genuinely shared across all instances - a counter, a cache, a constant. If two objects could reasonably hold different values, it should be an instance field instead.
• Use a static method when the result depends only on the arguments, not on any object's state (pure utility functions).
• Default to instance members. Overusing static quietly turns your program into a pile of global state, which is hard to test and reason about. static is the exception, not the starting point.

Next: Enums

A static final constant is fine for one fixed value, but when you have a small, fixed set of related values - directions, days of the week, order statuses - Java has a purpose-built type that is safer and more expressive than scattered constants. That is the enum, and it is the next page.