Objects, References, and Member Access in Java SE 25
These ten questions distinguish object construction, reference initialization, static membership, inheritance, and access permissions.
What are common ways to invoke an accessible method?
Answer: Code can call an in-scope method by simple name, invoke an instance method through a compatible reference, or invoke an inherited method where access rules allow it. Static methods are best called through the declaring type name. These are common forms, not an exhaustive count of all invocation syntax.
For instance methods, the receiver's runtime class can determine which override executes. Compile-time checks still govern whether the method is accessible and applicable. Super can explicitly select superclass behavior; imports and an omitted dot do not establish that a method is static.
What do creating, constructing, and instantiating an object mean?
Answer: In ordinary class usage, these describe producing a new instance, commonly with new and a constructor invocation. Construction initializes the object according to Java's initialization rules. A reference variable then refers to the instance; it is not the instance itself.
The JVM's abstract storage model places class instances and arrays on the heap, but optimizing implementations may eliminate allocations when behavior is preserved. Do not infer physical storage from a source variable alone. A factory method may return a cached existing object, so calling a factory does not always imply a fresh allocation.
Is every unassigned reference automatically null?
Answer: Reference fields and reference-array elements receive the default value null. Local variables do not receive a usable default value: the compiler requires definite assignment before a local variable is read. The literal is lowercase null.
public class ReferenceDefaults { private String field; public static void main(String[] args) { ReferenceDefaults holder = new ReferenceDefaults(); String[] array = new String[1]; String local = null; System.out.println(holder.field == null); System.out.println(array[0] == null); System.out.println(local == null); } }This prints true three times because the local was explicitly assigned null. Removing that initializer and then reading local causes a compilation error. Dereferencing a null value to invoke an instance method normally causes NullPointerException.
How can you tell whether a field or method is static?
Answer: Inspect its declaration or API documentation for static. Call syntax alone is not reliable: instance members can be used without an explicit dot in an instance context, and static members can be referred to by simple name when in scope or statically imported.
Conversely, Java permits certain static accesses through an expression, though that style is misleading. Use the type name to make static membership clear. Static members have no implicit current receiver; an instance member needs an object context or explicit reference.
What does this refer to?
Answer: In an instance context, this refers to the current receiver or the object under construction. It can distinguish a field from a parameter with the same name, as in
this.name = name;. It is not available in a static context.Inside a lambda, this retains its meaning from the enclosing context; a lambda does not introduce a new receiver. An anonymous class does have its own instance. Java SE 25's flexible constructor bodies also impose early-construction restrictions, so permission to write statements before super does not mean arbitrary use of the not-yet-constructed receiver is allowed.
Does a subclass inherit private members from its superclass?
Answer: No. Private superclass members are not inherited by the subclass. However, a subclass instance still contains the state initialized for its superclass part; superclass methods can operate on that private state.
Use an accessible superclass API when a subclass needs controlled behavior, rather than treating private storage as absent. Nested classes within the same enclosing top-level class have special private-access privileges, but that accessibility does not turn a private method into an inherited or overridable method.
Can a subclass override a private superclass method?
Answer: No. A method with the same signature declared in the subclass is a separate method, not an override of the private method. Applying Override to that declaration fails unless it independently overrides another eligible declaration.
Calls to the superclass's private method continue to refer to its own implementation. This differs from dynamic dispatch of accessible overridable instance methods. Saying that a subclass âknows nothingâ about private methods is imprecise; the important rules concern inheritance, access, and overriding, which are separate concepts.
Why is omitted access often called package access?
Answer: For an ordinary class member with no access modifier, access is restricted to code in the declaring package. The rule is based on package membership, not on whether the caller happens to be a subclass.
An import does not grant package access. Subpackages are also distinct packages: code in example.internal is not automatically inside example. Context matters because interface members have different implicit modifiers. There is no default access keyword to add to a class field.
How does protected differ from package access?
Answer: Both permit access from the declaring package. Protected additionally permits eligible subclass access outside that package, subject to restrictions. For an instance member accessed through a qualifying reference in the subclass's cross-package code, the reference type must be that subclass or a subtype of it.
A subclass cannot use protected as though the member were public on every superclass instance. Access through this or super is a common valid form. Protected constructors have their own rules, so constructor access should not be inferred blindly from field access examples.
Can a subclass in another package access a package-access superclass member?
Answer: Not directly merely by being a subclass. Moving the subclass to another package loses the ordinary same-package access permission. Importing the superclass or writing its fully qualified name does not restore that permission.
An accessible method on the superclass can expose an intended operation while keeping implementation details hidden. Change visibility only when the API design calls for it; do not make a field public just to suppress a compilation error. Package access and protected access serve different extension boundaries.
References: Initial variable values, Accessibility, and Inheritance and constructors.