Difficulty: Easy
Correct Answer: From any class in the same package and from subclasses even if they are in different packages
Explanation:
Introduction / Context:
The protected access modifier in Java is specifically designed to support inheritance while still providing some level of encapsulation. It is often misunderstood, especially when packages and subclasses across package boundaries are involved. Interview questions about protected help confirm that you know exactly where such members are visible.
Given Data / Assumptions:
Concept / Approach:
In Java, a protected member has two main visibility rules. First, it is visible to any class in the same package, similar to default (package private) access. Second, it is visible to subclasses, including subclasses that are defined in a different package. However, subclasses in a different package must access the protected member through inheritance (for example, using this or super), not through a reference to an unrelated instance of the superclass.
Step-by-Step Solution:
1. If ClassA defines a protected method doWork(), then ClassB in the same package can call new ClassA().doWork() because protected is visible within the package.
2. If ClassC extends ClassA in the same package, it can call doWork() directly inside its own methods.
3. If ClassD in another package extends ClassA, it can call doWork() within its methods, for example this.doWork() or super.doWork().
4. However, ClassD cannot generally call doWork() on an arbitrary ClassA instance created elsewhere if there is no inheritance relationship for that particular reference.
5. Classes in completely different packages that do not extend ClassA cannot access doWork() at all.
Verification / Alternative check:
You can verify this behavior by writing small examples with packages such as pkg1 and pkg2. Define a superclass in pkg1 with a protected method and then try to access it from non subclass classes in pkg2 and from subclass classes in pkg2. Compilation errors will show where access is not allowed, confirming the rules for protected.
Why Other Options Are Wrong:
Option B describes private access, not protected, since private members are visible only inside the defining class. Option C describes public access, where any class anywhere can access the member. Option D is nonsensical because protected does not give access only to classes in unrelated packages; it always includes same package visibility and subclass visibility.
Common Pitfalls:
A frequent misunderstanding is to think that protected members are visible only in subclasses and not in the same package, or vice versa. Another pitfall is accessing protected members of a superclass through a variable that is not the current instance when working across packages. Keeping the exact rules in mind helps design class hierarchies that are both flexible and well encapsulated.
Final Answer:
From any class in the same package and from subclasses even if they are in different packages.
Discussion & Comments