Packages & access: interview questions & scenarios

Model answer

"Same class" means the whole top-level class body, including nested classes. With Java 9 modules, public reaches other modules only if the package is exported.

Model answer

// package com.acme.base
public class Base { protected int count; }

// package com.acme.app
public class Child extends Base {
    void a()              { count++; }        // ✅ through this
    void b(Child other)   { other.count++; }  // ✅ reference of my own type
    void c(Base other)    { other.count++; }  // ❌ count has protected access in Base
}

Outside the package, a subclass may access a protected instance member only through this, super, or a reference whose static type is the subclass (or a subclass of it). other in c could be a Sibling extends Base, and Child isn't responsible for Sibling's implementation.

Model answer

No. A top-level class can only be public or package-private. private and protected are defined relative to an enclosing class, and a top-level class has none, so the compiler rejects them ("modifier private not allowed here"). A file can contain at most one public top-level class, and it must be named after it. Nested classes can use any of the four levels.

Model answer

Because private is scoped to the top-level class body, which includes all nested classes. At the JVM level, Outer and Outer$Inner are separate class files, though. Before Java 11, javac generated synthetic package-private bridge methods (access$000) so the inner class could reach the private field. Since Java 11 (JEP 181, nestmates), class files record NestHost and NestMembers attributes and the JVM allows private access between nestmates directly. No bridges, smaller class files, and reflection follows the same rule.

Model answer

class Parent { public void start() {} }
class Child extends Parent {
    protected void start() {}   // ❌ attempting to assign weaker access privileges; was public
}

An override must be at least as accessible as the method it overrides. Code holding a Parent reference is allowed to call start(); if the actual object were a Child that hid it, substitution would break. Widening (for example protected → public) is allowed.

Model answer

Nothing. import is a compile-time shortcut that tells javac how to expand simple names. The bytecode always contains fully qualified names (java/util/ArrayList). So wildcard imports cost nothing at runtime, unused imports cost nothing, and you could write every type fully qualified with no imports at all. Classes are loaded lazily when first used, regardless of imports.

Model answer

NoSuchMethodError at runtime means the code was compiled against a version of a class that has the method, but a different version was loaded. On the classpath the first matching class wins, so the usual cause is two versions of the same library (or a fat JAR that shades an old copy), with the old one earlier in the order. Steps:

1. Find which JAR the class came from: run with -verbose:class (or -Xlog:class+load=info) and grep for the class, or log Foo.class.getProtectionDomain().getCodeSource().getLocation().
2. Compare dependency trees between environments: mvn dependency:tree or gradle dependencies, looking for the library at two versions.
3. Fix by pinning one version (dependency management / constraints), excluding the transitive copy, or relocating (shading) it.

Model answer

Classes without a package statement are in the unnamed package, and nothing in a named package can import them: there's no name to put in the import (forbidden since Java 1.4). They also have no namespace, so two libraries with a default-package Utils collide silently on the classpath, and named modules can't contain them at all. It's fine for a one-file experiment and nothing else.

Model answer

A module groups packages and declares two things: which modules it requires, and which packages it exports. A public class in a package that isn't exported is not accessible to other modules, at compile time or by reflection. opens grants runtime deep reflection (for frameworks like Jackson) without exporting. The JDK uses this to hide jdk.internal.*, and since Java 16 and 17 internals are strongly encapsulated by default. Modules also forbid split packages, so the same package can't come from two modules.

module com.acme.billing {
    requires java.sql;
    exports com.acme.billing.api;
    opens com.acme.billing.model to com.fasterxml.jackson.databind;
}

Model answer

Start from the most restrictive level and widen only with a reason:

• Fields private (and final where possible). Expose behaviour, not state.
• Helpers private, or package-private if tests or collaborators in the package need them. Package-private is a good internal API.
• public only for the API you're willing to support across versions.
• protected only if you've designed for subclassing; it's part of the public contract since anyone can extend a non-final class. Otherwise make the class final.
• Don't leak mutable internals: return List.copyOf(items) rather than the internal list. Modifiers protect references, not the objects behind them.

Model answer

On the classpath, yes: field.setAccessible(true) lets reflection read and write private fields. Across modules, it only works if the target package is opened to the caller; otherwise it throws InaccessibleObjectException. That doesn't make private useless: access modifiers are a design and compiler-enforced contract that stops accidental misuse and lets you change internals safely, not a security sandbox against code running in the same JVM.