Package and Protected Access in Java SE 25

These questions explain how access checks work across packages and distinguish class modifiers from local-variable declarations.

1. Does importing a class make its package-access members accessible?

   Answer: No. An import changes how a name can be written, not whether the declaration is accessible. Package-access members of an ordinary class remain restricted to code in the declaring package.

   A subclass outside that package does not gain permission by importing its superclass. Likewise, a fully qualified name cannot bypass access checks. If outside callers need an operation, expose a deliberately designed accessible method rather than relying on import syntax.

2. How should package access be understood?

   Answer: It is a package boundary. Ordinary class members declared without public, protected, or private are accessible to code in their package, subject to the surrounding type being usable. Unrelated classes in that package can access them; inheritance is not required.

   Subpackages do not share this permission automatically. The word default is informal in this context and is not an access modifier. Interface fields and methods have their own implicit modifiers, so omission does not always mean package access.

3. What does protected access permit?

   Answer: It permits ordinary access within the declaring package and additional access from eligible subclass code outside that package. Cross-package instance-member access has a qualifier restriction: the reference used must have the accessing subclass's type or a subtype, rather than an arbitrary superclass type.

   Importing the superclass is optional if its qualified name is used and does not supply access rights. Also check accessibility of the superclass itself and, in named modules, the relevant exports and readability. Protected does not mean public to all code holding a subclass object.




4. Can a subclass change a protected superclass field?

   Answer: Yes, if the field is mutable and the access satisfies the protected rules. Protected controls accessibility; it does not prohibit assignment. Final and other language rules may independently prevent reassignment.

   A subclass can also override an eligible protected instance method and can widen its visibility. It cannot reduce an override's access. Exposing mutable fields to subclasses can make invariants harder to preserve, so protected operations around private state are often easier to maintain than freely writable protected fields.

5. Is a protected member accessible only through inheritance?

   Answer: No, not as a universal statement. Code in the declaring package can use protected members without being a subclass. Outside the package, access must occur in eligible subclass code and satisfy the additional protected-access restrictions.

   For instance members, this and super are common access forms, and a compatible subclass-typed reference can also be valid. An arbitrary superclass reference is not sufficient in that cross-package setting. Identify both the access location and the qualifier's type before deciding legality.

6. How can a subclass access protected instance state across packages?

   Answer: It can use its inherited state or a qualifying reference of its own subclass type or a subtype. These two files illustrate the rule.

   File: access/base/Parent.java

   package access.base;
   
   public class Parent {
       protected int value = 1;
       int packageValue;
   }

   File: access/client/Child.java

   package access.client;
   
   import access.base.Parent;
   
   public class Child extends Parent {
       void update(Child other) { other.value = 2; }
       public static void main(String[] args) {
           Child child = new Child();
           child.update(child);
           System.out.println(child.value);
       }
   }

   Compile both files with javac -d out and run java -cp out access.client.Child; the output is 2. Changing update's parameter type from Child to Parent makes other.value illegal here. The packageValue field is also inaccessible from Child's package, despite the import.




7. How should code be repaired after protected access is changed to package access?

   Answer: First decide whether outside subclass access is still intended. If it is, expose an appropriate protected or public operation, or retain protected access when that is the correct contract. An accessible getter can expose a value, but a setter should be added only if mutation is intended.

   Imports cannot repair the loss of permission. Moving code into the same package can change accessibility, but is an architectural decision rather than a universal fix. Existing clients may also be affected by such a visibility reduction, so review the compatibility implications.

8. Which modifiers can be used on a class declaration in Java SE 25?

   Answer: It depends on the declaration's context. An ordinary top-level class can have public or package access and can use applicable modifiers such as abstract, final, sealed, or non-sealed. Strictfp remains a legacy accepted modifier but no longer changes floating-point behavior.

   Member classes may additionally use private, protected, or static where permitted. Local classes follow different restrictions. Modifier combinations are constrained: a class cannot be both abstract and final, and non-sealed requires an appropriate sealed supertype. The old three-modifier list is not a complete Java SE 25 rule.





9. When can a subclass directly use a package-access superclass field?

   Answer: In the ordinary case, when the subclass's code is in the same package as the declaration. A subclass in a different package does not gain direct access through inheritance alone.

   Access is checked at the code location, not according to the runtime object's package. A method declared inside the superclass may still access its own field when invoked on a subclass instance. That does not imply the subclass's own source code can name the field.

10. Can access modifiers be applied to local variables?

    Answer: No. Public, protected, and private cannot modify local variables. A local's scope is determined by its declaration context. Final is permitted, but it is a non-access modifier that prevents reassignment after initialization.

    A final reference can still refer to a mutable object. Var requests local type inference rather than controlling access or mutability, and a local variable still requires definite assignment before use. An effectively final local can be captured by a lambda without explicitly writing final.

References: Protected access rules, Class modifiers, and Local variables.