☕ Java

Java Access Modifiers — public, private, protected & default

Everything you need to know about Java Access Modifiers — visibility rules, encapsulation, class-level vs member-level access, inheritance behaviour, interface rules, anti-patterns, and real-world production code examples.

📅

Last Updated

March 2026

⏱️

Read Time

24 min

🎯

Level

Beginner

🏷️

Chapter

18 of 35

What are Access Modifiers in Java?

Access modifiers (also called access specifiers) in Java are keywords that define the visibility and accessibility of classes, methods, constructors, and fields. They are the primary mechanism Java provides to implement encapsulation — the OOP principle of hiding internal implementation details and exposing only what is necessary.

Java provides four access modifiers: public, private, protected, and default (package-private — applied when no modifier keyword is written). Each defines a different level of visibility, ranging from completely open (public) to completely restricted (private).

In real-world applications, access control is everywhere: a BankAccount class keeps its balance field private so only its own methods can modify it. A paymentGateway method is public so external systems can call it. An internal helper method like validateCVV() is private so no outside class can bypass security. This careful control is what separates robust production code from fragile code that anyone can break.

public Modifier — Maximum Visibility

The public modifier grants unrestricted access from anywhere in the program — the same class, the same package, subclasses in different packages, and completely unrelated classes in other packages. It is the most permissive modifier. public is used for class definitions that form the API — the intentional public contract that other code is meant to use.

📌

Where public Can Be Applied

• Top-level classes (the class itself) • Methods (instance and static) • Fields/variables (though usually combined with final for constants) • Constructors • Interfaces and their members • Enum declarations • Nested/inner classes

📋

Visibility Scope

Accessible from: ✅ Same class ✅ Same package ✅ Subclass in same package ✅ Subclass in different package ✅ Non-subclass in different package → No restrictions — visible from everywhere in the program.

⚠️

One public Class Per File Rule

A .java file can contain ONLY ONE public top-level class, and the filename MUST match that class name exactly (case-sensitive). Example: PublicDemo.java must contain 'public class PublicDemo'. Violating this is a compile-time error. A file can have multiple non-public (default) classes, but only one public class.

☕ JavaPublicModifierDemo.java

// File: PublicModifierDemo.java
// public class — accessible from anywhere
public class PublicModifierDemo {

    // public field — accessible from anywhere (avoid for mutable state)
    public static final double TAX_RATE = 0.18; // ✅ OK — constant

    // public mutable field — BAD PRACTICE (exposed to modification)
    public String name; // ❌ Avoid — use private + getter/setter

    // public constructor — anyone can instantiate
    public PublicModifierDemo(String name) {
        this.name = name;
    }

    // public method — part of the API contract
    public double calculateTax(double amount) {
        return amount * TAX_RATE;
    }

    // public static utility method
    public static String formatCurrency(double amount) {
        return String.format("₹%.2f", amount);
    }
}

// File: AnotherPackage/OtherClass.java (different package)
import com.techsustainify.PublicModifierDemo;

public class OtherClass {
    public void demo() {
        // ✅ Can access public class from different package
        PublicModifierDemo obj = new PublicModifierDemo("Test");

        // ✅ Can access public method
        double tax = obj.calculateTax(1000);

        // ✅ Can access public static method
        String formatted = PublicModifierDemo.formatCurrency(1180);

        // ✅ Can access public constant
        double rate = PublicModifierDemo.TAX_RATE;

        System.out.println(formatted + " (Tax: " + tax + ")");
    }
}

private Modifier — Maximum Restriction

The private modifier is the most restrictive access level. A private member is accessible only within the class where it is declared — not from subclasses, not from other classes in the same package, not from anywhere else. private is the correct default for all class fields and implementation-detail methods, forming the foundation of encapsulation.

📌

Where private Can Be Applied

• Fields/variables (most common use) • Methods (helper/utility methods) • Constructors (Singleton pattern, factory pattern) • Nested/inner classes • ❌ Cannot be applied to top-level classes

📋

Visibility Scope

Accessible from: ✅ Same class only ❌ Same package (other classes) ❌ Subclass in same package ❌ Subclass in different package ❌ Other packages → Total isolation within the declaring class.

🔒

Why private is the Right Default

Start everything as private. Only promote visibility (to protected or public) when external access is genuinely required. This is the 'Principle of Least Privilege' — give the minimum access needed. It enables: safe refactoring (internals can change freely), validation before state changes (via setters), immutability (no setter = immutable field), and better encapsulation.

☕ JavaBankAccount.java — private in Action

public class BankAccount {

    // ✅ private fields — no outside code can directly modify balance
    private String accountNumber;
    private String ownerName;
    private double balance;
    private boolean frozen;

    // ✅ public constructor — outsiders can create accounts
    public BankAccount(String accountNumber, String ownerName, double initialDeposit) {
        this.accountNumber = accountNumber;
        this.ownerName     = ownerName;
        // Validation in constructor — impossible with public fields
        if (initialDeposit < 0) {
            throw new IllegalArgumentException("Initial deposit cannot be negative");
        }
        this.balance = initialDeposit;
        this.frozen  = false;
    }

    // ✅ public API methods — controlled access to private state
    public void deposit(double amount) {
        validateNotFrozen();
        if (amount <= 0) throw new IllegalArgumentException("Deposit must be positive");
        balance += amount;
        logTransaction("DEPOSIT", amount);
    }

    public void withdraw(double amount) {
        validateNotFrozen();
        if (amount <= 0) throw new IllegalArgumentException("Amount must be positive");
        if (amount > balance) throw new IllegalStateException("Insufficient funds");
        balance -= amount;
        logTransaction("WITHDRAWAL", amount);
    }

    public double getBalance() {
        return balance; // Read-only access — no setter for balance
    }

    public String getAccountNumber() { return accountNumber; }
    public String getOwnerName()     { return ownerName; }

    // ✅ private helper methods — implementation details hidden
    private void validateNotFrozen() {
        if (frozen) throw new IllegalStateException("Account is frozen");
    }

    private void logTransaction(String type, double amount) {
        System.out.printf("[LOG] %s: ₹%.2f | Balance: ₹%.2f%n", type, amount, balance);
    }
}

// Usage:
// BankAccount acc = new BankAccount("ACC001", "Ravi", 5000);
// acc.deposit(2000);   // ✅ Works
// acc.balance = 99999; // ❌ Compile error — private field
// acc.logTransaction(); // ❌ Compile error — private method

protected Modifier — Inheritance-Aware Access

The protected modifier grants access to the same class, same package, AND all subclasses — even subclasses in different packages. It sits between default (package-only) and public (everywhere). protected is designed specifically for inheritance scenarios — when a parent class wants to share implementation details with its children without exposing them to the entire world.

📌

Where protected Can Be Applied

• Methods (intended for subclass use or override) • Fields (shared internal state with subclasses) • Constructors (force subclassing — e.g., abstract base class) • Nested/inner classes • ❌ Cannot be applied to top-level classes

📋

Visibility Scope

Accessible from: ✅ Same class ✅ Same package (all classes) ✅ Subclass in same package ✅ Subclass in different package ❌ Non-subclass in different package → Key: package OR subclass, but NOT arbitrary outside classes.

🔗

protected vs default — Key Difference

Both allow same-package access. The difference: protected ALSO allows subclass access across packages. default does NOT. If you have a class in package 'com.app.base' with a default method, and a subclass in 'com.app.ui', the subclass CANNOT access that method. Make it protected to enable cross-package inheritance while still blocking arbitrary external code.

☕ JavaProtectedModifierDemo.java

// Package: com.techsustainify.shapes
public abstract class Shape {

    // protected field — subclasses can access and set this
    protected String color;
    protected double borderWidth;

    // protected constructor — forces use of subclasses
    protected Shape(String color, double borderWidth) {
        this.color       = color;
        this.borderWidth = borderWidth;
    }

    // public abstract method — subclasses MUST implement
    public abstract double calculateArea();

    // protected method — shared logic for subclasses, hidden from outside
    protected String getBaseDescription() {
        return String.format("Color: %s, Border: %.1fpx", color, borderWidth);
    }

    // protected utility for rendering — subclasses may override or call
    protected void drawBorder() {
        System.out.println("Drawing border: width = " + borderWidth);
    }
}

// Package: com.techsustainify.ui  (DIFFERENT package)
import com.techsustainify.shapes.Shape;

public class Circle extends Shape {

    private double radius;

    public Circle(double radius, String color) {
        super(color, 1.0); // ✅ Can call protected parent constructor
        this.radius = radius;
    }

    @Override
    public double calculateArea() {
        return Math.PI * radius * radius;
    }

    public String describe() {
        // ✅ Can access protected parent method from subclass (different package)
        return "Circle [r=" + radius + "] | " + getBaseDescription();
    }

    public void render() {
        drawBorder(); // ✅ Can call protected parent method
        // ✅ Can access protected field directly
        System.out.println("Filling circle with color: " + color);
    }
}

// In a completely unrelated class (different package, NOT a subclass):
// Shape s = ...;
// s.drawBorder();       // ❌ Compile error — protected, not a subclass
// s.getBaseDescription(); // ❌ Compile error — protected

default (Package-Private) Modifier — Package-Level Access

The default access modifier — also called package-private — is applied when no access modifier keyword is written. A member with default access is visible to all classes within the same package but is completely hidden from classes in other packages, including subclasses in different packages. It is the "internal to this package" visibility level.

📌

How to Apply Default Access

Simply write NOTHING — no keyword at all: • class DatabaseHelper { } // default class • void executeQuery() { } // default method • int rowCount; // default field Do NOT write 'default' as a keyword for access — 'default' is only a keyword in switch and interface default methods, not as an access modifier.

📋

Visibility Scope

Accessible from: ✅ Same class ✅ Same package (all classes) ❌ Subclass in different package ❌ Non-subclass in different package → Package boundary is the visibility limit.

📦

When to Use Default Access

Use default access for: (1) Implementation classes not meant to be in the public API — e.g., a Helper or Impl class. (2) Package-internal utilities shared among classes in the same module/package. (3) Classes intentionally restricted to a bounded context (Domain-Driven Design bounded contexts). Well-designed Java packages often have 1-2 public API classes and several default (internal) classes.

☕ JavaDefaultAccessDemo.java

// Package: com.techsustainify.payment

// ✅ Default (package-private) class — internal implementation
// Not accessible from other packages — intentional
class PaymentValidator {

    // Default method — only classes in same package can call this
    boolean isValidAmount(double amount) {
        return amount > 0 && amount <= 1_000_000;
    }

    // Default method — internal package utility
    boolean isValidCurrency(String currency) {
        return currency != null && (currency.equals("INR") || currency.equals("USD"));
    }
}

// Package: com.techsustainify.payment (SAME package)
// ✅ PaymentProcessor can use PaymentValidator freely
public class PaymentProcessor {

    private PaymentValidator validator = new PaymentValidator(); // ✅ Same package

    public boolean processPayment(double amount, String currency) {
        if (!validator.isValidAmount(amount)) {    // ✅ Accessible — same package
            System.out.println("Invalid amount");
            return false;
        }
        if (!validator.isValidCurrency(currency)) { // ✅ Accessible — same package
            System.out.println("Unsupported currency");
            return false;
        }
        System.out.println("Processing " + currency + " " + amount);
        return true;
    }
}

// Package: com.techsustainify.ui (DIFFERENT package)
import com.techsustainify.payment.PaymentProcessor;
// import com.techsustainify.payment.PaymentValidator; // ❌ Cannot import — default class

public class CheckoutUI {
    public void checkout() {
        PaymentProcessor proc = new PaymentProcessor(); // ✅ public class
        proc.processPayment(1500.0, "INR");             // ✅ public method

        // PaymentValidator v = new PaymentValidator();   // ❌ Compile error
        // v.isValidAmount(500);                          // ❌ Compile error
    }
}

Access Modifier Comparison Table — At a Glance

This table summarises the complete visibility matrix for all four Java access modifiers across every possible access location.

Access Location	private	default	protected	public
Same class	✅ Yes	✅ Yes	✅ Yes	✅ Yes
Same package — subclass	❌ No	✅ Yes	✅ Yes	✅ Yes
Same package — non-subclass	❌ No	✅ Yes	✅ Yes	✅ Yes
Different package — subclass	❌ No	❌ No	✅ Yes	✅ Yes
Different package — non-subclass	❌ No	❌ No	❌ No	✅ Yes
Applicable to top-level class?	❌ No	✅ Yes	❌ No	✅ Yes
Applicable to class members?	✅ Yes	✅ Yes	✅ Yes	✅ Yes
Applicable to constructors?	✅ Yes	✅ Yes	✅ Yes	✅ Yes
Supports encapsulation?	✅ Best	✅ Good	⚠️ Limited	❌ No
Overridable in subclass?	❌ No	⚠️ Same pkg	✅ Yes	✅ Yes

Class-Level vs Member-Level Access — Two Distinct Contexts

Access modifiers work at two distinct levels in Java: the class level (controlling access to the class itself) and the member level (controlling access to fields, methods, and constructors inside the class). The rules are different at each level, and confusing them is a common source of errors.

🏛️

Class-Level Access (Top-Level Classes)

Top-level classes can only be public or default (package-private). They CANNOT be private or protected — this is a compile-time error. A public class is accessible from any package. A default class is only accessible from within its own package. One .java file = maximum one public class (must match filename).

🔧

Member-Level Access (Fields, Methods, Constructors)

Members of a class can use all four modifiers: private, default, protected, and public. Member-level access is determined first by the class-level access. Even if a method is public, if the class itself is default (package-private), outside packages cannot reach that method — the class is not even visible to them.

🏠

Nested Class Access

Inner classes (nested inside another class) can use all four modifiers. A private inner class is accessible only within the enclosing class. A public inner class is accessible anywhere (though the outer class must also be reachable). Static nested classes follow the same rules as regular classes.

☕ JavaClassVsMemberAccess.java

// ✅ public top-level class — accessible from other packages
public class Order {

    // Member-level modifiers — all four are valid here
    private   int orderId;          // Only Order class
    double    totalAmount;          // Default — same package only
    protected String customerName;  // Package + subclasses
    public    String orderStatus;   // Everywhere (but bad practice for mutable field)

    // private constructor — prevents direct instantiation (factory pattern)
    private Order(int orderId) {
        this.orderId = orderId;
        this.orderStatus = "PENDING";
    }

    // public factory method — the intended way to create orders
    public static Order create(int orderId) {
        if (orderId <= 0) throw new IllegalArgumentException("Invalid order ID");
        return new Order(orderId);
    }

    // ✅ private nested class — only Order can use this
    private class OrderItem {
        String productName;
        int quantity;
        double price;
    }

    // ✅ default nested class — accessible in same package
    class OrderAuditLog {
        void log(String event) {
            System.out.println("Order #" + orderId + ": " + event);
        }
    }
}

// ❌ private class MyClass { }   // Compile error — top-level class cannot be private
// ❌ protected class MyClass { } // Compile error — top-level class cannot be protected

Access Modifiers with Inheritance — Overriding Rules

Access modifiers interact with inheritance in specific, important ways. When a subclass overrides a parent method, Java enforces a critical rule: the overriding method cannot reduce visibility — it can only maintain or widen the access level. This ensures that code relying on the parent's interface continues to work with any subclass (Liskov Substitution Principle).

✅

Widening Access — Allowed

An overriding method CAN increase visibility: • protected → public ✅ • default → protected ✅ • default → public ✅ • private → (cannot override, so not applicable) Widening is always safe — if callers could call the parent version, they can certainly call a more accessible version.

❌

Narrowing Access — Compile Error

An overriding method CANNOT reduce visibility: • public → protected ❌ Compile error • public → default ❌ Compile error • public → private ❌ Compile error • protected → default ❌ Compile error Narrowing would break code that expects the parent's public interface to work on any subclass.

🚫

private Methods — Cannot Be Overridden

Private methods are not visible to subclasses, so they CANNOT be overridden. If a subclass declares a method with the same name and signature as a parent's private method, it is a completely NEW method — not an override. Using @Override annotation on it causes a compile error. This is called method hiding (for static methods) or simply a new unrelated method (for instance methods).

☕ JavaAccessWithInheritance.java

// Package: com.techsustainify.vehicle
public class Vehicle {

    private String vin;          // Not inherited — completely private
    protected String fuelType;   // Accessible in subclasses
    public String brand;         // Accessible everywhere

    protected void startEngine() {
        System.out.println("Vehicle engine started");
    }

    public String getInfo() {
        return "Brand: " + brand + " | Fuel: " + fuelType;
    }

    private void performInternalDiagnostic() {
        System.out.println("Internal diagnostic — private");
    }
}

public class ElectricCar extends Vehicle {

    private int batteryCapacity;

    public ElectricCar(String brand, int batteryCapacity) {
        this.brand           = brand;       // ✅ Inherited public field
        this.fuelType        = "Electric";  // ✅ Inherited protected field
        this.batteryCapacity = batteryCapacity;
    }

    // ✅ WIDENING access: protected → public (allowed)
    @Override
    public void startEngine() {
        System.out.println("Electric motor activated silently");
    }

    // ✅ MAINTAINING access: public → public (same level, always allowed)
    @Override
    public String getInfo() {
        return super.getInfo() + " | Battery: " + batteryCapacity + "kWh";
    }

    // ❌ Would be NARROWING — compile error:
    // @Override
    // protected String getInfo() { } // ERROR — cannot reduce from public to protected

    // This is a NEW method, NOT an override of private performInternalDiagnostic()
    public void performInternalDiagnostic() {
        System.out.println("EV diagnostic — battery, motor, regenerative braking");
        // Cannot call: super.performInternalDiagnostic(); // ❌ private — not visible
    }
}

Encapsulation — The Core Purpose of Access Modifiers

Encapsulation is one of the four pillars of object-oriented programming (alongside Inheritance, Polymorphism, and Abstraction). It means bundling data (fields) and the methods that operate on that data into a single unit (class), while restricting direct access to the data. Access modifiers are the mechanism that makes encapsulation possible in Java.

🔒

Data Hiding

Make all fields private. External code cannot directly read or modify internal state. Every access goes through controlled methods. Benefit: the class can enforce invariants — guarantees about its own state that should always hold (e.g., age can never be negative, balance can never go below minimumBalance).

🚪

Controlled Access via Getters/Setters

Provide public getters (read access) and optionally public setters (write access) for fields that need external visibility. Setters can validate input before modifying state. Read-only fields have a getter but no setter. Write-only fields (rare) have a setter but no getter. This gives you full control over every read and write.

🔄

Freedom to Change Internals

Once fields are private, you can change their internal representation at any time without breaking callers. Example: storing a phone number as String internally but exposing it as a formatted PhoneNumber object through the getter. Or switching from ArrayList to LinkedList for an internal collection. Callers never know — they only use the public API.

☕ JavaEncapsulatedEmployee.java

public class Employee {

    // ✅ ALL fields private — enforces controlled access
    private final int    employeeId;   // Immutable — no setter
    private       String name;
    private       String department;
    private       double salary;
    private       int    age;

    public Employee(int employeeId, String name, String department,
                    double salary, int age) {
        if (employeeId <= 0)   throw new IllegalArgumentException("Invalid ID");
        if (salary < 0)        throw new IllegalArgumentException("Salary cannot be negative");
        if (age < 18 || age > 65) throw new IllegalArgumentException("Age out of range");
        if (name == null || name.isBlank()) throw new IllegalArgumentException("Name required");

        this.employeeId = employeeId;
        this.name       = name;
        this.department = department;
        this.salary     = salary;
        this.age        = age;
    }

    // Read-only getter (no setter — ID is final/immutable)
    public int getEmployeeId() { return employeeId; }

    // Standard getter and setter with validation
    public String getName() { return name; }
    public void setName(String name) {
        if (name == null || name.isBlank()) throw new IllegalArgumentException("Name required");
        this.name = name;
    }

    public double getSalary() { return salary; }
    public void setSalary(double salary) {
        if (salary < 0) throw new IllegalArgumentException("Salary cannot be negative");
        this.salary = salary;
    }

    public int getAge() { return age; }
    public void setAge(int age) {
        if (age < 18 || age > 65) throw new IllegalArgumentException("Age out of range");
        this.age = age;
    }

    // Business method — uses private state without exposing it
    public double calculateBonus() {
        if (salary > 100000) return salary * 0.20;
        if (salary > 50000)  return salary * 0.15;
        return salary * 0.10;
    }

    @Override
    public String toString() {
        return String.format("Employee[id=%d, name=%s, dept=%s, salary=%.2f]",
                            employeeId, name, department, salary);
    }
}

Access Modifiers in Interfaces — Special Rules

Interfaces in Java have special access modifier rules that differ from classes. Understanding these is essential for writing correct Java interfaces, especially since Java 8, 9, and later versions added default, static, and private methods to interfaces.

📜

Interface Methods

• Abstract methods: implicitly public — no other modifier allowed (private/protected/default cause compile error in abstract context). • default methods (Java 8+): must be public (explicitly or implicitly). • static methods (Java 8+): must be public (default) or private (Java 9+). • private methods (Java 9+): allowed — used as internal helpers for default/static methods. NOT inherited by implementing classes.

📦

Interface Fields

All fields in an interface are implicitly: public, static, and final — i.e., they are constants. You cannot make interface fields private or protected. Writing 'int MAX = 100;' in an interface is automatically 'public static final int MAX = 100;'. Attempting to assign them in implementing classes is a compile error.

🏛️

Interface Itself

A top-level interface can only be public or default (package-private) — same as classes. A public interface is accessible everywhere. A default interface is package-private. Nested interfaces inside a class can be public, protected, default, or private. When implementing an interface method, the implementing class method MUST be public — it cannot reduce visibility.

☕ JavaInterfaceAccessModifiers.java

// Public interface — accessible everywhere
public interface PaymentGateway {

    // Implicitly: public static final
    int MAX_RETRY_COUNT = 3;             // ✅ Constant
    double TRANSACTION_FEE_PERCENT = 2.5; // ✅ Constant

    // Implicitly: public abstract — no modifier needed
    boolean processPayment(double amount, String currency);
    void refund(String transactionId);

    // ✅ default method (Java 8+) — implicitly public
    default String formatAmount(double amount, String currency) {
        return String.format("%s %.2f", currency, amount);
    }

    // ✅ static method (Java 8+) — implicitly public
    static boolean isSupportedCurrency(String currency) {
        return currency != null &&
               (currency.equals("INR") || currency.equals("USD") || currency.equals("EUR"));
    }

    // ✅ private method (Java 9+) — helper for default methods
    private void logAttempt(String operation) {
        System.out.println("[Gateway] Attempting: " + operation);
    }

    // ✅ private static method (Java 9+)
    private static String buildRequestId() {
        return "REQ-" + System.currentTimeMillis();
    }
}

// Implementing class MUST use public for all interface methods
public class UPIGateway implements PaymentGateway {

    @Override
    public boolean processPayment(double amount, String currency) { // ✅ Must be public
        System.out.println("UPI payment: " + formatAmount(amount, currency));
        return true;
    }

    @Override
    public void refund(String transactionId) {
        System.out.println("UPI refund for: " + transactionId);
    }

    // ❌ Cannot do this — would narrow interface's public to protected
    // @Override
    // protected boolean processPayment(...) { } // Compile error
}

Common Mistakes & Pitfalls — Errors That Fool Everyone

These mistakes appear consistently in Java beginner and intermediate code. Each one either causes a compile-time error or — worse — silently violates the encapsulation principle, creating fragile code that breaks during maintenance.

☕ JavaAccessModifierMistakes.java

// ❌ MISTAKE 1: public mutable fields — breaks encapsulation
public class Product {
    public double price;  // ❌ Anyone can set: product.price = -999;
    public int stock;     // ❌ No validation possible
}
// ✅ Fix: private fields with validated setters
public class Product {
    private double price;
    private int stock;
    public void setPrice(double price) {
        if (price < 0) throw new IllegalArgumentException("Price cannot be negative");
        this.price = price;
    }
    public double getPrice() { return price; }
}

// ❌ MISTAKE 2: Making a class private at top level
// private class Config { }  // Compile error — top-level class cannot be private

// ❌ MISTAKE 3: Narrowing access in subclass override
class Animal {
    public void speak() { System.out.println("..."); }
}
class Dog extends Animal {
    // @Override
    // protected void speak() { }  // ❌ Compile error — narrows public to protected
    @Override
    public void speak() { System.out.println("Woof!"); } // ✅ Same or wider
}

// ❌ MISTAKE 4: Expecting protected to mean 'subclass only'
// (In same package, ALL classes — not just subclasses — can access protected members)
package com.example;
class Parent {
    protected int secret = 42;
}
class UnrelatedSamePkg {  // NOT a subclass
    void demo() {
        Parent p = new Parent();
        System.out.println(p.secret); // ✅ Works! Same package, not just subclasses
    }
}

// ❌ MISTAKE 5: Overriding private method (it is not an override)
class Base {
    private void helper() { System.out.println("Base helper"); }
    public void run() { helper(); } // Calls Base's private helper
}
class Derived extends Base {
    // This is a NEW method — NOT an override
    private void helper() { System.out.println("Derived helper"); }
    // run() in Base still calls Base's private helper — polymorphism does NOT apply
}
// new Derived().run() → prints 'Base helper', NOT 'Derived helper'

// ❌ MISTAKE 6: Forgetting that interface methods implementing must be public
interface Flyable {
    void fly();
}
class Bird implements Flyable {
    // void fly() { }          // ❌ Reduces public to default — compile error
    public void fly() { }      // ✅ Must explicitly be public

Bad Practices & Anti-Patterns — What Senior Developers Reject

These access modifier anti-patterns are among the top reasons for failed code reviews in professional Java teams. Each one violates fundamental OOP principles and creates long-term maintenance problems.

🚫

God Class with All-Public Fields

A class where all fields are public is not encapsulation — it is a glorified struct. Any class can modify its state directly, making it impossible to enforce invariants, add validation, or refactor internals. Every field should start private. Only promote visibility when genuinely needed, and almost never to public for mutable fields.

🚫

Anemic Domain Model

A class with all-private fields but only getters and setters, with no business logic — just data containers. This is anti-OOP. Business logic that works with the data belongs IN the class, not scattered in service classes. An Employee should have calculateBonus(), not just getSalary()/setSalary(). Tell, don't ask.

🚫

Using protected Instead of private by Default

Making all fields protected 'in case subclasses need them' is lazy access control. protected exposes internals to the entire package AND all future subclasses. This tightly couples parent and child classes, making the parent hard to refactor. Keep fields private; provide protected methods if subclasses need specific behaviour — not raw field access.

🚫

Unnecessary Public API — Leaking Internals

Making internal helper methods public because 'it might be useful later' pollutes the public API. Once public, removing or renaming a method is a breaking change. Every public method is a contract you must maintain forever. Use private or package-private for implementation details. Add to public API only with deliberate intent.

🚫

Breaking Encapsulation via Returning Mutable References

Returning a reference to a private mutable collection or array defeats encapsulation even with a private field: 'public List<Order> getOrders() { return orders; }' — the caller now holds a direct reference to the internal list and can modify it. Return a defensive copy: 'return Collections.unmodifiableList(orders)' or 'return new ArrayList<>(orders)'.

🚫

Reflection to Access Private Members

Using Java Reflection to access private fields (field.setAccessible(true)) in production code is an extreme violation of encapsulation — it bypasses all access control. It makes code brittle (breaks when field names change), causes security issues in modular Java (Java 9+ module system blocks this), and signals a design flaw. If external code needs access, provide a proper API.

☕ JavaAccessAntiPatterns.java

// ❌ ANTI-PATTERN: Returning mutable internal collection
public class ShoppingCart {
    private List<Item> items = new ArrayList<>();

    public List<Item> getItems() {
        return items;  // ❌ Caller gets direct reference — can modify!
    }
}
// Usage of broken API:
// cart.getItems().clear(); // ❌ Clears internal list — bypasses all control!

// ✅ FIX: Return defensive copy or unmodifiable view
public class ShoppingCart {
    private List<Item> items = new ArrayList<>();

    // Option 1: Unmodifiable view — throws on mutation attempt
    public List<Item> getItems() {
        return Collections.unmodifiableList(items);
    }

    // Option 2: Defensive copy — independent copy, mutations don't affect internal state
    public List<Item> getItemsCopy() {
        return new ArrayList<>(items);
    }

    // ✅ BEST: Provide specific methods instead of exposing the collection
    public void addItem(Item item) {
        if (item == null) throw new IllegalArgumentException("Item cannot be null");
        items.add(item);
    }

    public int getItemCount() { return items.size(); }
    public boolean hasItem(String productId) {
        return items.stream().anyMatch(i -> i.getProductId().equals(productId));
    }
}

// ❌ ANTI-PATTERN: Reflection to bypass private
// Field field = SomeClass.class.getDeclaredField("privateField");
// field.setAccessible(true); // ❌ Breaks encapsulation, brittle, security risk
// field.set(obj, newValue);
// → If you need this in production code, the design has a problem — fix the API.

Real-World Production Code Examples — Access Modifiers in Context

The following examples show access modifier usage patterns found in real enterprise Java codebases — Spring Boot application layers with deliberate, idiomatic access control at each level.

☕ JavaUserAccount.java — Domain Model with Encapsulation

package com.techsustainify.domain;

import java.time.LocalDateTime;
import java.util.ArrayList;
import java.util.Collections;
import java.util.List;

public class UserAccount {

    // private — core identity fields, immutable after creation
    private final String userId;
    private final String email;
    private final LocalDateTime createdAt;

    // private — mutable but controlled state
    private String displayName;
    private boolean active;
    private boolean emailVerified;
    private int loginAttempts;
    private LocalDateTime lastLoginAt;

    // private — internal collection never exposed directly
    private final List<String> roles = new ArrayList<>();

    // package-private constructor — only factory/builder in same package creates instances
    UserAccount(String userId, String email, String displayName) {
        this.userId      = userId;
        this.email       = email;
        this.displayName = displayName;
        this.createdAt   = LocalDateTime.now();
        this.active      = true;
        this.emailVerified = false;
        this.loginAttempts = 0;
    }

    // public read-only accessors for immutable fields
    public String getUserId()          { return userId; }
    public String getEmail()           { return email; }
    public LocalDateTime getCreatedAt(){ return createdAt; }

    // public controlled mutators with business logic
    public String getDisplayName() { return displayName; }
    public void setDisplayName(String displayName) {
        if (displayName == null || displayName.isBlank())
            throw new IllegalArgumentException("Display name cannot be blank");
        if (displayName.length() > 50)
            throw new IllegalArgumentException("Display name too long");
        this.displayName = displayName;
    }

    // Business state — read publicly, changed only through business methods
    public boolean isActive()        { return active; }
    public boolean isEmailVerified() { return emailVerified; }

    // Business methods — encapsulate state transitions with rules
    public void verifyEmail() {
        this.emailVerified = true;
    }

    public void deactivate() {
        this.active = false;
    }

    public void recordSuccessfulLogin() {
        this.loginAttempts = 0;
        this.lastLoginAt = LocalDateTime.now();
    }

    public boolean recordFailedLogin() {
        this.loginAttempts++;
        if (this.loginAttempts >= 5) {
            this.active = false;
            return false; // Account locked
        }
        return true;
    }

    public void addRole(String role) {
        if (!roles.contains(role)) roles.add(role);
    }

    // ✅ Unmodifiable view — callers read roles, cannot modify internal list
    public List<String> getRoles() {
        return Collections.unmodifiableList(roles);
    }

    public boolean hasRole(String role) {
        return roles.contains(role);
    }

    // private helper — implementation detail
    private boolean isLoginLocked() {
        return loginAttempts >= 5;
    }
}

☕ JavaAbstractRepository.java — protected Template Method Pattern

package com.techsustainify.data;

import java.util.List;
import java.util.Optional;

// Abstract base — default (package-private) access — internal framework class
abstract class AbstractRepository<T, ID> {

    // protected — subclasses must access this to perform DB operations
    protected final DatabaseConnection connection;

    protected AbstractRepository(DatabaseConnection connection) {
        this.connection = connection;
    }

    // public API — these are the operations callers use
    public abstract Optional<T> findById(ID id);
    public abstract List<T> findAll();
    public abstract T save(T entity);
    public abstract void deleteById(ID id);

    // protected template methods — shared infrastructure, overridable behaviour
    protected void beforeSave(T entity) {
        // Default: no-op. Subclasses can override to add audit timestamps.
    }

    protected void afterSave(T entity) {
        // Default: no-op. Subclasses can override to publish domain events.
    }

    // private — internal framework utility, hidden even from subclasses
    private void checkConnectionHealth() {
        if (!connection.isHealthy()) {
            throw new DatabaseException("Connection unhealthy");
        }
    }
}

// public concrete class — this is what application code sees
public class UserRepository extends AbstractRepository<UserAccount, String> {

    public UserRepository(DatabaseConnection connection) {
        super(connection); // ✅ Calls protected parent constructor
    }

    @Override
    public Optional<UserAccount> findById(String userId) {
        // ✅ Uses protected connection field from parent
        return connection.query("SELECT * FROM users WHERE id = ?", userId);
    }

    @Override
    protected void beforeSave(UserAccount user) {
        // ✅ Overrides protected template — adds audit timestamp
        user.setLastModified(LocalDateTime.now());
    }

    @Override
    public List<UserAccount> findAll()              { /* implementation */ return null; }
    @Override
    public UserAccount save(UserAccount entity)     { /* implementation */ return null; }
    @Override
    public void deleteById(String id)               { /* implementation */ }
}

Access Modifier Decision Flowchart — Which One to Use?

Use this decision flowchart when choosing the right access modifier for any class member.

▶ Choosing access modifierfor a field, method, or constructor

Start

🔍 Needed ONLY inside this class?no external access ever required

YES

✅ Use privatemost restrictive — correct default

🔍 Needed in same package only?not needed by other packages

YES

✅ Use default (no keyword)package-private — internal to package

🔍 Needed in subclasses too?cross-package inheritance required

YES

✅ Use protectedpackage + subclass access

✅ Use publicpart of public API — visible everywhere

Code Execution Flow — from source to output

Java Access Modifier Interview Questions — Beginner to Advanced

These questions are consistently asked in Java fresher and experienced developer interviews, campus placements, and OCPJP/OCA certification exams.

Java has four access modifiers in order from most restrictive to least restrictive: (1) private — accessible only within the declaring class. (2) default (no keyword) — accessible within the same package. (3) protected — accessible within the same package AND in subclasses across packages. (4) public — accessible from everywhere. Memory aid: private < default < protected < public. Each level is a superset of the previous: public includes everything protected does, which includes everything default does.

No. Top-level classes (declared directly in a .java file, not inside another class) can ONLY be public or default (package-private). Declaring a top-level class as private or protected is a compile-time error. The reason: private would mean only the same class can access it — which is meaningless for a top-level class. protected would mean package + subclasses — but subclassing requires the class to be visible first, creating a circular dependency. Inner classes (nested inside another class), however, CAN use all four modifiers.

Both allow access from the same package. The critical difference: protected ALSO allows access from subclasses in DIFFERENT packages, while default does NOT. Example: class Parent with a default method in 'com.app.base'. A subclass in 'com.app.ui' CANNOT access that method. Make it protected and the subclass CAN access it. So: default = package boundary only. protected = package boundary + inheritance bridge across packages. Use protected deliberately for template methods, shared internal state, or constructors of abstract base classes.

No — this is a compile-time error. Java's override rules require that the overriding method's access level be the SAME or WIDER than the parent's. This enforces the Liskov Substitution Principle: if code works with a Parent reference, it must work equally well with any subclass reference. Narrowing visibility would break this guarantee. Allowed widening: protected → public ✅. Same level: public → public ✅. Narrowing: public → protected ❌ (compile error). The only exception: private methods cannot be overridden at all — they are not inherited.

No. Private methods are not visible to subclasses — they are completely hidden within the declaring class. Therefore they cannot participate in Java's method overriding (dynamic dispatch). If a subclass declares a method with the same name and signature as a parent's private method, Java treats it as a BRAND NEW method in the subclass — not an override. Adding @Override annotation to such a method causes a compile error confirming no override occurred. This is an important distinction: private methods are fully excluded from the inheritance mechanism.

The default access modifier is package-private visibility — applied when NO modifier keyword is written. It has no keyword — writing 'default' as an access modifier is a compile error. Confusingly, Java uses the word 'default' in two other contexts: (1) switch statement default case: 'default: ...' — completely unrelated. (2) Interface default methods (Java 8+): 'default void method() {}' — provides a default implementation, must be public. These three uses of 'default' are entirely different language features that happen to share a keyword. For access control, silence = package-private.

Interface method access depends on the method type: Abstract methods (traditional): implicitly public — no explicit modifier allowed. Writing protected/private/default causes a compile error. Default methods (Java 8+): implicitly public — must be public. Static methods (Java 8+): implicitly public, but can be private (Java 9+). Private methods (Java 9+): must be explicitly private — used as internal helpers for default/static methods. NOT inherited by implementing classes. When a class implements an interface method, that implementation MUST be public — it cannot reduce the interface's implicit public contract.

The public method is only reachable by code that can first reach the class. If the class itself is package-private (default), then code in other packages cannot see the class at all — so even though the method is technically public, outside-package code cannot call it. The class acts as a visibility ceiling. This is intentional design: you can have a package-internal class with public methods (so same-package code calls them cleanly) while preventing those methods from being part of the external API.

Encapsulation is the OOP principle of bundling data (fields) and the methods that operate on that data into a class, while restricting direct external access to the internal data. Access modifiers enforce encapsulation: private fields ensure external code cannot directly read or modify internal state. Public methods provide a controlled interface — with validation, logging, and business logic — for all access. This gives three key benefits: (1) Invariant enforcement — invalid states are impossible because all modifications go through controlled setters. (2) Refactoring freedom — internal representation can change without breaking callers. (3) API stability — public interface is stable while implementation evolves.

No — this is one of the most commonly misunderstood Java rules. A subclass in a different package can access a protected member through its OWN reference (this.protectedField or just protectedField) or through super. But it CANNOT access the protected member through a variable of the parent type. Example: inside class Child extends Parent (different package), 'this.protectedField' is ✅ valid, but 'Parent p = new Parent(); p.protectedField' is ❌ a compile error — even inside Child. This prevents unrelated objects of the parent type from being accessible through a subclass's inheritance privilege.

Practice Questions — Test Your Access Modifier Knowledge

Attempt each question independently before reading the answer — active recall significantly improves retention.

1. Identify the access modifier issue: public class Circle { public double radius; public double area; public Circle(double radius) { this.radius = radius; this.area = Math.PI * radius * radius; } }

Easy

✅ AnswerTwo issues: (1) 'radius' is public and mutable — anyone can set 'circle.radius = -5' or 'circle.radius = 100' without recalculating area, leaving the object in an inconsistent state. (2) 'area' should be computed, not stored as a public field — it must stay in sync with radius, which is impossible when both are public. Fix: make both fields private, provide 'getRadius()' and a 'setRadius(double r)' that also recalculates area, or better — make radius final (set once via constructor) and calculate area on demand via 'getArea() { return Math.PI * radius * radius; }'. Immutable radius = no sync problem.

2. Will this compile? If not, why? private class Config { private String dbUrl; private int port; }

Easy

✅ AnswerCompile error IF Config is a top-level class (declared directly in a .java file). Top-level classes can only be public or default — not private. The error is: 'modifier private not allowed here'. Fix: either remove 'private' to make it package-private (default), or make it 'public'. If Config is an INNER class (declared inside another class), then 'private class Config' is perfectly valid — private inner classes are fully supported and commonly used to hide helper classes.

3. What is the output? package com.a; public class Parent { protected int value = 10; } package com.b; import com.a.Parent; public class Child extends Parent { public void show() { System.out.println(value); // Line A Parent p = new Parent(); System.out.println(p.value); // Line B } }

Medium

✅ AnswerLine A compiles and prints 10. Line B causes a COMPILE ERROR. This is the protected cross-package access rule: A subclass (Child) in a different package (com.b) CAN access a parent's protected member through its OWN reference (Line A — 'value' implicitly means 'this.value'). However, it CANNOT access the protected member through a Parent-type reference (Line B — 'p.value') from a different package. The inheritance privilege only applies to the subclass's own inherited copy, not to arbitrary parent-type objects.

4. Fix the encapsulation violation: public class Team { public List<String> members = new ArrayList<>(); public String teamName; }

Medium

✅ AnswerFixed version: public class Team { private String teamName; private List<String> members = new ArrayList<>(); public Team(String teamName) { if (teamName == null || teamName.isBlank()) throw new IllegalArgumentException(); this.teamName = teamName; } public String getTeamName() { return teamName; } public void addMember(String member) { if (member != null && !member.isBlank()) members.add(member); } public void removeMember(String member) { members.remove(member); } public List<String> getMembers() { return Collections.unmodifiableList(members); } public int getMemberCount() { return members.size(); } } — Fields are private, collection exposed as unmodifiable, business methods control all mutations.

5. Is the following override valid? Why or why not? class Vehicle { public void start() { System.out.println("Starting"); } protected void stop() { System.out.println("Stopping"); } } class Truck extends Vehicle { @Override protected void start() { System.out.println("Truck starting"); } @Override public void stop() { System.out.println("Truck stopping"); } }

Medium

✅ Answerstart() override: COMPILE ERROR. Truck tries to reduce 'start()' from public (Vehicle) to protected (Truck). This narrows access — illegal in Java. Override rule: visibility can only stay the same or increase. Fix: 'public void start()' in Truck. stop() override: VALID. Truck widens 'stop()' from protected (Vehicle) to public (Truck). Widening is always allowed. This is correct overriding. Summary: protected → public ✅ (widening), public → protected ❌ (narrowing — compile error).

6. What is the output and why? class Animal { private void sound() { System.out.println("Animal sound"); } public void makeSound() { sound(); } } class Dog extends Animal { public void sound() { System.out.println("Woof"); } } public class Main { public static void main(String[] args) { Animal a = new Dog(); a.makeSound(); } }

Hard

✅ AnswerOutput: 'Animal sound'. This demonstrates that private methods are NOT polymorphic. Dog.sound() is NOT an override of Animal.sound() — it is a completely new, unrelated method. Animal.makeSound() calls 'sound()' which resolves to Animal's own private sound() at compile time (static binding). Even though 'a' holds a Dog object at runtime, the private method call in Animal.makeSound() is bound to Animal.sound() — Dog's sound() is invisible to Animal. This is a classic interview trap. If sound() were public/protected in Animal, Dog.sound() would be a proper override and 'Woof' would print.

7. Design a class using all four access modifiers appropriately for a Library system book checkout.

Hard

✅ Answerpublic class LibraryBook { private final String isbn; private final String title; private boolean checkedOut; private String borrowerName; private int checkoutCount; protected static final int MAX_RENEWAL_DAYS = 14; public LibraryBook(String isbn, String title) { this.isbn = isbn; this.title = title; this.checkedOut = false; this.checkoutCount = 0; } public String getIsbn() { return isbn; } public String getTitle() { return title; } public boolean isAvailable() { return !checkedOut; } public void checkOut(String borrower) { if (checkedOut) throw new IllegalStateException("Already checked out"); this.checkedOut = true; this.borrowerName = borrower; this.checkoutCount++; } public void returnBook() { if (!checkedOut) throw new IllegalStateException("Not checked out"); this.checkedOut = false; this.borrowerName = null; } int getCheckoutCount() { return checkoutCount; } // default — package-level reporting private boolean isPopular() { return checkoutCount > 50; } } — private: isbn, title, checkedOut, isPopular(). default: getCheckoutCount() for package reporting. protected: MAX_RENEWAL_DAYS for subclass LibraryEBook. public: checkout API.

8. What is wrong with this interface implementation? interface Printable { void print(); } class Document implements Printable { void print() { System.out.println("Printing document"); } }

Easy

✅ AnswerCompile error: Document.print() reduces the interface method's implicit public access to default (package-private). Interface abstract methods are implicitly public. When a class implements an interface method, it must use the same or wider access — which means it MUST be public. The error is: 'print() in Document cannot implement print() in Printable; attempting to assign weaker access privileges; was public'. Fix: 'public void print() { System.out.println("Printing document"); }'. This is a very common mistake for developers coming from languages with different interface rules.

Conclusion — Access Modifiers: The Gatekeepers of Java OOP

Access modifiers are not just a syntactic detail — they are the architectural foundation of well-designed Java code. They enforce encapsulation, define public contracts, protect internal invariants, and make codebases maintainable as they grow. Every field, method, and class you write deserves a deliberate access modifier choice — not a default assumption.

The golden rule professionals follow: start with the most restrictive modifier and only promote when genuinely necessary. Begin every field as private. Begin every helper method as private. Promote to default when package-level sharing is needed. Promote to protected only for deliberate inheritance contracts. Promote to public only for the intentional external API. This discipline — called the Principle of Least Privilege — is what separates maintainable enterprise Java from fragile, tightly-coupled code.

Modifier	Keyword	Scope	Primary Use Case
private	private	Same class only	Fields, internal helpers, Singleton constructors
default	(none)	Same package	Package-internal classes, utilities, impl classes
protected	protected	Same package + subclasses (cross-package)	Template methods, shared state for inheritance
public	public	Everywhere	Public API: service methods, constructors, constants

Your next step: Java Encapsulation — where you will see how private fields combined with public getters and setters create truly robust, maintainable domain objects, and how encapsulation ties together with immutability and the Builder pattern in modern Java applications. ☕

Frequently Asked Questions — Java Access Modifiers

Access modifiers in Java are keywords that control the visibility and accessibility of classes, methods, constructors, and fields. Java provides four access levels: public (accessible from anywhere), protected (same package and subclasses), default/package-private (same package only — no keyword), and private (same class only). They are the primary mechanism for implementing encapsulation — restricting internal details and exposing only what is necessary.

private: most restrictive — accessible only within the declaring class. protected: accessible within the same package AND in subclasses across packages. public: least restrictive — accessible from anywhere in the program. The rule: always use the most restrictive modifier that still allows your code to function. Start with private for fields and helpers, use public only for the intentional external API.

The default access modifier (package-private) is applied when no modifier keyword is written. A member with default access is visible to all classes within the same package but completely hidden from classes in other packages — including subclasses in different packages. It has no keyword — writing 'default' as an access modifier is a compile error. It is suitable for package-internal implementation classes and utilities not meant to be part of the public API.

No. Private methods are not visible to subclasses, so they cannot be overridden. If a subclass declares a method with the same signature as a parent's private method, it creates an entirely new unrelated method in the subclass — not an override. Using @Override on such a method causes a compile error. Private methods are also not polymorphic — calls to private methods are resolved at compile time (static binding), not at runtime.