Java Access Modifiers: public, protected, default, and private

Java has four access levels, arranged from most restrictive to least. Three of them are keywords you write. The fourth has no keyword at all, and the name people use for it, default, is not part of the language. Writing it is rejected outright:

public class DefTest {
    default void x() {
    }
}// error: modifier default not allowed here

Package-private access is what you get by writing nothing. Here is one class using all four levels, which is the shape most real code settles into:

package com.acme.billing;
public class AccessDemo {
    private String ledgerKey() {
        return "sk-live-4821";
    } // this class only
    String feeFor(long units) {
        ...
    } // the package
    protected double rate() {
        return 0.075;
    } // package + subclasses
    public String receipt(String id) {
        ...
    } // everywhere visible
}

The order of declaration in that snippet is deliberate and is the conventional one: narrowest first, widest last. It reads as a widening of the surface area, and it makes the intended API obvious at a glance.

Read the "nested class" column carefully, because it is the one most people get wrong. A nested class is inside the declaring class, so it can reach that class's private members with no ceremony at all:

class Auditor {
    String peek() {
        return ledgerKey();
        // legal, no accessor needed
    }
}

That has been true in principle for a long time, but the mechanism changed. Before Java 11 the compiler generated synthetic bridge methods to let this work. Since Java 11 classes that reference one another this way are compiled as a single nest, and the JVM grants nestmates access to each other's private members directly. No bridge methods are generated, and the rule is now enforced by the runtime rather than papered over by the compiler.

protected is the only modifier with a condition attached to it, and the condition is the single most common surprise in this topic. Protected means "the whole package, plus subclasses in other packages", but outside the package a subclass may only reach the inherited member through a reference whose type is that subclass or a further descendant of it.

Here is the case that fails, with the exact error:

// package p1
public class Base {
    protected int value = 7;
}// package p2
public class Child extends p1.Base {
    int readDirect() {
        return value;
    } // fine
    int readWrong(p1.Base other) {
        return other.value;
    } // error: value has protected access in Base
}

Both lines touch the same field on the same inherited member. The first is the subclass using something it inherited, which is what protected is for. The second reaches through a variable typed as the superclass, which the language treats as code outside the subclass reaching in, and refuses.

The reasoning behind the rule is sound. If any subclass could read the field through any superclass-typed reference, then a subclass of Base could reach into a completely unrelated part of the object graph and mutate state it is not responsible for. Java makes you go through your own type so that the access stays inside the part of the object the subclass actually owns.

The practical consequence is that if you need to read an inherited protected member from a method that only has a supertype reference, you have to cast, or add an accessor on the subclass:

int readWrongFixed(p1.Base other) {
    return((Child) other).value;
    // now the reference type is Child
}

Inside the same package this never comes up, because package access already allows the direct read. The trap only exists at a package boundary.

A private member is not inherited in any sense that matters. A subclass may declare a method with the same name and signature, and the compiler will accept it, but that creates an entirely new, unrelated method:

class PremiumAccount extends AccessDemo {
    @Override public String feeFor(long units) {
        ...
    } // a real override
    String ledgerKey() {
        return "UNRELATED";
    } // NOT an override
}

Adding @Override to the second one is what turns the mistake into a compile error, which is the cheapest way to catch it. A subclass also cannot narrow access when overriding, so a package-private method may be widened to public but never the reverse. The full set of rules for that lives on the method overriding page; the point here is only that the two topics meet at the modifier.

Everything above is checked by javac, which is why the errors arrive at compile time. That is not the whole story, because the JVM performs its own check on the class file as it loads and links it. The rules are encoded in the access flags of the class file and enforced again at run time.

The place you meet this is reflection. Looking up a private member and invoking it without permission fails while the program is running:

Method m = Holder.class.getDeclaredMethod("secret");
m.invoke(new Holder());
// IllegalAccessException
m.setAccessible(true);
m.invoke(new Holder());
// "classified"

Three lines of output from a program that does exactly that:

public method, no setAccessible = openprivate, no setAccessible = IllegalAccessExceptionprivate, with setAccessible = classified

That second check is why a class can compile cleanly and still fail later. It is also the reason access rules are respected even when the compiler is not in the picture, such as for classes loaded by a different loader or deserialised from untrusted bytes.

One nuance worth knowing, because it looks like a contradiction when you first hit it: reflection from inside the same nest does not throw. Calling the same private method from a nested class succeeds without setAccessible, for exactly the reason described earlier, because both classes share a nest.

Interface members are all public. You cannot write private or protected on an interface method, and omitting public is not the same as omitting it on a class. Reflection confirms what is stored:

interface Shape {
    double area();
    int SIDES = 1;
    class Nested {
    }
}Method m = Shape.class.getMethod("area");
Modifier.toString(m.getModifiers());
// "public abstract"
Field f = Shape.class.getDeclaredField("SIDES");
Modifier.toString(f.getModifiers());
// "public static final"

A class declared inside an interface is also implicitly public static. This follows from the topic covered on the interfaces page, where the implicit modifiers were shown for methods and fields; nested types follow the same rule.

A top-level class may only be public or package-private. The other two modifiers are meaningless for a type that nothing can extend yet:

private class Hidden {
}// error: modifier private not allowed here
protected class AlsoHidden {
}// error: modifier protected not allowed here

On a nested class all four are legal, because by then there is something to extend and something to be extended by. The restriction is about position in the file, not about the modifier itself.

This is the part that makes the four modifiers feel incomplete, and it arrives with Java 9. A class can be perfectly public and still be unreachable, because its package may not be exported by its module.

// com.acme.lib/module-info.java
module com.acme.lib {
    exports com.acme.api;
    // this package is visible
    // com.acme.internal is NOT listed, so it stays private to the module
}

With that declaration, an application module may import the exported package:

// com.acme.app/module-info.java
module com.acme.app {
    requires com.acme.lib;
}

import com.acme.api.Api;
// compiles and runs
import com.acme.internal.Hidden;
// error: package com.acme.internal is not visible
//   (package com.acme.internal is declared in module com.acme.lib,
//    which does not export it)

Both halves of that were run to confirm the wording. The permitted import compiles, the module launches, and the forbidden one is rejected at compile time with a message naming the module that is withholding it.

This is why public alone no longer means "anywhere". Access now has two independent questions: is the member public, and is its package exported. Both must be yes. On the classpath without modules, everything sits in an unnamed module which exports everything, so the familiar behaviour returns and most code never notices the difference.

The modifiers are not a style ladder to climb. A useful default is to make the narrowest thing that works public, and to keep the public surface small enough that you can remember it.

• Fields. Private, always. Expose through accessors when a caller needs them, so you keep the option to add validation later.
• Methods that are called from outside the package. Public, and expect to support them.
• Methods for subclasses you do not control. Protected. If nobody extends the class, use private and final.
• Package-internal helpers. Leave the modifier off. It is the right default for code you share inside one package.

Two habits pay for themselves quickly. Put the narrowest modifier first and the widest last in each class, so a reader can see the intended surface without parsing every line. And add @Override to anything that implements or overrides a parent member, because it converts a mistaken re-declaration of a private method into a compile error instead of a method that is never called.

Frequently Asked Questions

What are the four access modifiers in Java and what does each allow?

private allows the declaring class only, plus any nested class in the same nest. Package-private, written by omitting the modifier, allows every type in the same package. protected allows the whole package plus subclasses in other packages, subject to a condition on the reference type. public allows anywhere the declaring class is itself visible, which since Java 9 also depends on whether the module exports the package.

Is default a keyword in Java?

No. Package-private access is expressed by writing no modifier at all. Using the word default produces the error "modifier default not allowed here". The name is a convenient label used in discussion, but it is not part of the language, and the reserved word list does not contain it.

Can a subclass access a private method of its parent?

No. A private method is not inherited, so a subclass that declares a method with the same name is defining something new and unrelated rather than overriding anything. Adding @Override to that declaration is what turns the mistake into a compile error. A nested class is a different case: it can reach the enclosing class's private members directly, because the two share a nest.

Why can a subclass not read a protected field through a superclass reference?

Because outside the package, protected access is only permitted through a reference of the subclass's own type. Reading an inherited member directly is fine, but going through a variable typed as the superclass is treated as unrelated code reaching in, and is rejected with "value has protected access in Base". Cast the reference to the subclass type if that access is genuinely what you need.

Can a nested class be private?

Yes. All four modifiers are legal on a nested class. The restriction applies only to top-level types, where private and protected produce "modifier not allowed here", since nothing outside the file could extend or reach such a type in the first place.

Are interface methods always public?

Yes, and you cannot mark them otherwise. An interface method without a body is stored as public abstract, an interface field as public static final, and a class declared inside an interface as public static. Since Java 9 a private method is allowed inside an interface, but only to share implementation between its own default methods.

Does public guarantee that a class is reachable?

Not by itself, since Java 9. A class must be public and its package must be exported by its module before another module can use it, and the error names the withholding module explicitly. Code on the ordinary classpath lives in the unnamed module, which exports everything, so the old behaviour returns and the distinction only bites modular builds.

Is access checked at compile time or at run time?

Both. javac rejects an unreachable member before the program starts, and the JVM checks the access flags in the class file again as it loads and links. The runtime check is what makes reflection throw IllegalAccessException for a private member unless setAccessible(true) was called first.

Can an override reduce visibility?

No. An override may widen access but never narrow it, so a public parent method cannot become protected or private in the child. The reasoning is substitutability: code holding a supertype reference was promised access to that method and must keep it. Widening, on the other hand, is always allowed.

What is the best default access level for a field?

Private, with accessors where callers genuinely need one. Fields are mutable state, and a private field with a getter lets you add validation, caching, or deprecation later without breaking anyone. The exception worth considering is a genuinely immutable constant, which is often written public static final or exposed through a package-private accessor for a small group of collaborating classes.