Access Modifiers

What Are Access Modifiers?

An access modifier is a keyword that controls which parts of your code can see and use a class, method, or field. Java provides four levels: private, package-private (no keyword), protected, and public. Together they are the primary tool for implementing encapsulation — one of the four pillars of OOP.

The problem they solve: in any non-trivial program, not everything should be accessible from everywhere. If every field and method is public, any part of the codebase can read or modify internal state directly — making it impossible to change the implementation without breaking every caller, and impossible to guarantee that an object is always in a valid state.

// Without access control: anyone can corrupt state
            public class User {
                public String password;  // anyone can read or overwrite this
                public int    age;       // anyone can set age = -999
            }
            
            user.password = "plaintext";  // no hashing, no validation, no control
            user.age = -999;             // completely invalid, silently accepted
            
            // With access control: the class enforces its own rules
            public class User {
                private String passwordHash;  // internal detail, hidden
                private int    age;
            
                public void setPassword(String raw) {
                    this.passwordHash = hash(raw);  // always hashed, no exceptions
                }
                public void setAge(int age) {
                    if (age < 0) throw new IllegalArgumentException("Invalid age");
                    this.age = age;
                }
            }

The Four Access Levels

Access modifiers are the primary tool for encapsulation in Java — they control what parts of your code are visible to other classes. The rule is simple: start with private and widen only when something genuinely needs it. Every unnecessary public method or field is a commitment you'll have to maintain forever.

* Protected access in a subclass from a different package only works through inheritance (this/super), not on arbitrary instances of the parent class.

Each Modifier in Detail

private — the default you should reach for

public class BankAccount {
    // Fields: always private — never expose raw state
    private String accountNumber;
    private double balance;
    private String pin;

    // Public API: controlled operations with validation
    public double getBalance() { return balance; }

    public boolean withdraw(double amount, String enteredPin) {
        if (!validatePin(enteredPin) || amount <= 0 || amount > balance) return false;
        balance -= amount;
        logTransaction("WITHDRAW", amount);
        return true;
    }

    // Private helpers: implementation detail, free to change anytime
    private boolean validatePin(String p) { return this.pin.equals(p); }
    private void    logTransaction(String type, double amount) { ... }
}

// ❌ These are compile errors from any other class:
// account.balance = 1_000_000;   private access
// account.validatePin("0000");    private access

package-private (no modifier) — internal implementation

No keyword needed — just omit the modifier. Useful for implementation classes that belong to a module but shouldn't be part of its public API.

// com/app/internal/UserRepository.java
package com.app.internal;

class UserRepository {          // ← no modifier = package-private
    User findById(long id) { ... }
    void save(User user) { ... }
}

// com/app/service/UserService.java — DIFFERENT package
import com.app.internal.UserRepository;  // ❌ ERROR: not visible

/*
 *  com.mylib
 *  ├── api/           ← public classes only — this IS your API
 *  │   ├── UserService.java   (public)
 *  │   └── User.java          (public)
 *  └── internal/      ← package-private classes — implementation detail
 *      ├── UserRepository.java   (package-private)
 *      └── CacheManager.java     (package-private)
 *
 *  Library users can only see api/. You can refactor internal/ freely.
 */

protected — for inheritance extension points

protected means same-package access PLUS subclasses in any package. The key nuance: subclass access only works via this/super, not on an arbitrary parent instance.

// package: com.app.model
public class Animal {
    protected String name;      // accessible in subclasses
    private   String internalId;  // NOT accessible even in subclasses

    protected void makeSound() { }  // override hook
}

// package: com.app.pets  (DIFFERENT package)
public class Dog extends Animal {
    @Override
    protected void makeSound() {
        System.out.println(name + " barks");  // ✅ protected field via 'this'
    }

    void weirdAccess(Animal other) {
        // other.name = "x";   ❌ NOT allowed — different pkg, not via inheritance
        this.name = "Rex";    // ✅ allowed — own inherited field
    }
}

public — your API contract

public class UserService {
    public static final int MAX_USERNAME_LENGTH = 50;  // OK: constant

    public User    createUser(String username, String email) { ... }
    public Optional<User> findByUsername(String username) { ... }
    public void     deleteUser(long id) { ... }

    // These are private — users of UserService don't need to know about them
    private void    validateInput(String input) { ... }
    private void    saveToDatabase(User user) { ... }
}

// ❌ Anyone can set password to anything — no validation possible
public class User { public String password; }

// ✅ Controlled: validation lives in one place, changeable without breaking API
public class User {
    private String passwordHash;

    public void setPassword(String raw) {
        if (raw.length() < 8) throw new IllegalArgumentException("Too short");
        this.passwordHash = hash(raw);
    }
}

// ✅ Exception: public static final constants are fine
public static final int MAX_SIZE = 100;

Private Constructors

Two canonical patterns use private constructors to control instantiation:

// PATTERN 1: Utility class — no instances allowed
public final class MathUtils {
    private MathUtils() {
        throw new AssertionError("Utility class");
    }
    public static int square(int n) { return n * n; }
}

// PATTERN 2: Singleton — exactly one instance
public class AppConfig {
    private static final AppConfig INSTANCE = new AppConfig();

    private AppConfig() { }  // nobody else can instantiate

    public static AppConfig getInstance() { return INSTANCE; }
}
// Note: in Spring/CDI apps, singletons are managed by the container — you
// rarely write Singleton pattern manually in modern enterprise Java.

Encapsulation in Practice

Defensive copies for mutable fields

// ❌ BAD: caller can mutate your internal state
public class Team {
    private List<Player> players = new ArrayList<>();

    public List<Player> getPlayers() { return players; }
}
team.getPlayers().clear();  // 💥 wipes the team's roster

// ✅ GOOD option 1: unmodifiable view (no copy overhead)
public List<Player> getPlayers() {
    return Collections.unmodifiableList(players);
}

// ✅ GOOD option 2: defensive copy (caller gets independent list)
public List<Player> getPlayers() {
    return new ArrayList<>(players);
}

// ✅ MODERN: return immutable copy (Java 10+)
public List<Player> getPlayers() {
    return List.copyOf(players);
}

The principle of least privilege — applied

public class OrderProcessor {

    // Fields: always private
    private final OrderRepository repository;
    private final EmailService    emailService;

    // Constructor: public — callers need to build it
    public OrderProcessor(OrderRepository repo, EmailService email) {
        this.repository   = repo;
        this.emailService = email;
    }

    // Public API: what callers are allowed to do
    public Order process(OrderRequest request) {
        validate(request);
        Order order = buildOrder(request);
        repository.save(order);
        emailService.sendConfirmation(order);
        return order;
    }

    // Protected: extension hook for subclasses
    protected void validate(OrderRequest r) {
        if (r.quantity() <= 0) throw new IllegalArgumentException("Bad qty");
    }

    // Private: internal wiring nobody else needs to see
    private Order buildOrder(OrderRequest r) {
        return new Order(r.productId(), r.quantity(), LocalDateTime.now());
    }
}

Java 9+ Modules: Access Beyond Packages

The Java Platform Module System (JPMS), introduced in Java 9, adds a layer of access control above packages. A module explicitly declares what it exports — even public classes in unexported packages are inaccessible to other modules.

// module-info.java
module com.mylib {
    exports com.mylib.api;          // only api package is accessible
    // com.mylib.internal is NOT exported — invisible to all other modules
    // even if classes inside are public
}

// Another module:
module com.myapp {
    requires com.mylib;
    // Can use com.mylib.api.UserService (public + exported)
    // Cannot use com.mylib.internal.UserRepository (not exported)
}

Interview Questions