Access modifiers

Every Java developer can recite the four keywords, so interviewers don't stop there. They ask the questions that show whether you understand the rules: can a subclass in another package call protected methods on any parent object? Why can a nested class read its outer class's private fields? Why does overriding a public method as protected not compile? And as a design question: what should be public in the first place?

For this lesson, we'll focus on the four levels and the visibility matrix, the rules for top-level classes, the protected subtlety across packages, private access between nested classes (nestmates, Java 11), the overriding rule, how to choose a modifier, and how Java modules add another layer on top.

01Picture it first: rings of trust

Think of an office building. private is your locked desk drawer: only you, and the people who sit at your own desk (nested classes), can open it. Package-private is your team's room: anyone on the team walks in. protected adds trusted contractors from other teams who extend your work, under conditions. public is the lobby: open to everyone, and since Java 9 only if the building (the module) has unlocked its front door.

Fig. 1

Nested rings: private in the centre, then package-private, then protected, then public on the outside, with each ring including everything inside it

The same rules as a matrix, which is what you'd draw on a whiteboard:

Fig. 2

A grid showing which callers can see a member for each modifier: public everywhere, protected everywhere except unrelated classes in other packages, package-private only in the class and its package, private only in the class

Notice two things. Each level is a strict superset of the one below it, so "moving outward" always widens access. And the orange cell, protected from a subclass in another package, is the one with conditions attached.

02How it works under the hood

package com.acme.base;

public class Base {
    private   int secret;
    int           packageOnly;      // package-private: no keyword
    protected int count;
    public    int open;

    protected Base() {}
    protected void touch() {}
}

package com.acme.app;

import com.acme.base.Base;

public class Child extends Base {
    void demo(Child other, Base someBase) {
        open++;              // 1. ✅ public
        count++;             // 2. ✅ inherited protected member, accessed through this
        other.count++;       // 3. ✅ reference type is Child (my own type)
        someBase.count++;    // 4. ❌ count has protected access in Base
        packageOnly++;       // 5. ❌ package-private, different package
        // secret++;         //    ❌ private, never visible outside Base
    }
}

Lines 1 to 3 compile; lines 4 and 5 don't. Line 4 is the one most people get wrong, so let's look at why.

The protected subtlety (JLS 6.6.2)

Outside the package, protected doesn't mean "subclasses can touch this member on any object". It means a subclass can access it as part of implementing itself: through this, super, or a reference whose static type is the subclass (or one of its subclasses). Through a plain Base reference, the object might be some other subclass, say Sibling extends Base, and Child has no business touching Sibling's internals.

The same rule explains a puzzle you may have hit already:

Object o = new Object();
o.clone();   // ❌ clone() has protected access in Object

Your class is a subclass of Object, but o has static type Object, not your class, and you're not in java.lang. So the call fails, which is why classes that support cloning override clone() as public.

protected constructors follow a related rule: from another package, a subclass can call super(...) or create an anonymous subclass with new Base() {}, but not new Base() directly.

Top-level class rules

A top-level class (one not nested inside another) can only be public or package-private. private or protected on a top-level class is a compile error: there's no enclosing class for "private" to be relative to. A source file can contain at most one public top-level class, and the file must be named after it. Nested classes can use all four levels.

Private members and nested classes (nestmates, Java 11)

private is scoped to the top-level class body, not to the individual nested class. An inner class can read its outer class's private fields, and the outer class can call an inner class's private methods:

public class Outer {
    private int secret = 42;

    class Inner {
        int peek() { return secret; }      // ✅ same top-level class body
    }

    private static class Helper {
        private static String hidden() { return "ok"; }
    }

    String callHelper() { return Helper.hidden(); }   // ✅ also allowed
}

The JVM, however, used to see Outer and Outer$Inner as two unrelated classes in two class files, and its access check would reject one reading the other's private field. Before Java 11, javac papered over this by generating synthetic bridge methods like access$000: package-private static methods that effectively widened access to the private member. They bloated class files and confused stack traces.

Since Java 11 (JEP 181, nestmates), class files record a nest: Outer lists its NestMembers, each member points to its NestHost, and the JVM itself allows private access between nestmates. No bridges are needed, and reflection follows the same rule. You can check with javap -v Outer.class | grep -A2 NestMembers.

Overriding cannot reduce visibility

An overriding method must be at least as accessible as the method it overrides. Otherwise substitution would break: code holding a Base reference calls a public method, and the actual object would have hidden it.

class Parent { public void run() {} protected void step() {} }

class Kid extends Parent {
    protected void run() {}   // ❌ attempting to assign weaker access privileges; was public
    public void step() {}     // ✅ widening protected → public is fine
}

Two consequences show up in interviews. Methods implementing an interface must be public, because interface methods are implicitly public. And private methods aren't inherited at all, so a method with the same signature in a subclass is a brand-new method, not an override (that's why @Override on it fails to compile).

03Real world: choosing the right modifier

Here's the path I take, and it works for almost every class:

1. Fields: private, and final where possible. State is the thing you most need to protect. Expose behaviour, not data.
2. Helpers: private, or package-private if a test or a collaborator in the same package needs them. Package-private is a great "internal API" level: visible to your package, invisible to library users.
3. public only for the deliberate API. Every public member is a promise you'll have to keep across versions.
4. protected only when you've designed for inheritance. A protected member is part of your public contract, because anyone can subclass a non-final class and call it. If you didn't design for extension, make the class final instead.

public final class RateLimiter {
    private final int capacity;
    private int tokens;                       // state: private
    private long lastRefillNanos;

    public RateLimiter(int capacity) {        // API: public
        this.capacity = capacity;
        this.tokens = capacity;
        this.lastRefillNanos = System.nanoTime();
    }

    public synchronized boolean tryAcquire() {   // API: public
        refill();
        if (tokens == 0) return false;
        tokens--;
        return true;
    }

    void refill() { /* ... */ }               // package-private: testable, not exported to users
}

04Advanced: modules add another layer

Since Java 9, accessibility has two questions instead of one: is the member accessible by its modifier, and is its package exported to the caller's module?

module com.acme.ratelimit {
    exports com.acme.ratelimit.api;          // public types here are usable by other modules
    // com.acme.ratelimit.internal: public classes, but invisible outside this module
    opens com.acme.ratelimit.model to com.fasterxml.jackson.databind;   // deep reflection only
}

• public + exported package: usable from other modules (that requires this one).
• public + not exported: compile error from other modules, and reflection fails with IllegalAccessException or InaccessibleObjectException. This is how the JDK hides jdk.internal.* and, since Java 16 and 17, strongly encapsulates sun.* internals.
• opens allows reflection into a package at runtime, including private members, without exporting it at compile time. That's what serialisation and DI frameworks need.

So modules give you a fifth, coarse level: "public inside my module". Code on the classpath lives in the unnamed module, sees all exported packages, and keeps the old rules.

A few smaller rules that come up as follow-ups:

• Interface members are implicitly public (fields are public static final). Since Java 9 interfaces can have private methods to share code between default methods.
• Enum constructors are implicitly private; declaring one public or protected is a compile error.
• A package-private method can't be overridden from another package. A subclass in a different package that declares the same signature gets a new, unrelated method, and calls through the parent type still go to the parent's version.

05How to say it in the interview

When I ask about access modifiers, I'm listening for the precise rules, not just the keywords: that protected includes the package, that cross-package protected access goes through the subclass's own type, that private is scoped to the top-level class, and that overrides can't narrow access. Then I want to hear a design opinion: what's your default, and why.

             class  package  subclass(other pkg)  world
public         ✓       ✓            ✓              ✓
protected      ✓       ✓            ✓*             ✗
(default)      ✓       ✓            ✗              ✗
private        ✓       ✗            ✗              ✗
* only via this / super / ref of subclass type (JLS 6.6.2)
top-level: public | package-private only
private = whole top-level body → nestmates (Java 11, no access$000)
override: may widen, never narrow; interface impls must be public
modules: public + exported package = really public
default: private fields, pkg-private helpers, minimal public API