Java Questions 31 - 40  «Prev  Next»

Interfaces and Class Loading in Java SE 25

Review interface obligations, default methods, modern class loaders, and return types in overloaded methods.

  1. Must a concrete implementing class write every interface method itself?

    Answer: No. It must satisfy its required abstract instance methods, but compatible inherited methods and applicable default methods can provide implementations. Interface static methods and private helpers are not abstract obligations for an implementing class.

    A concrete class cannot leave a required abstract operation unresolved. Its implementation must also have the required public access, compatible return type, and permitted checked exceptions.

  2. What is the purpose of an interface contract?

    Answer: It gives callers a common set of operations and behavioral promises that different implementations can satisfy. A class's internal representation need not resemble another implementation's representation.

    For example, callers can use a List without depending on whether it stores elements in an array or linked nodes. Method declarations provide compile-time checks, while documentation defines expectations such as ordering, null handling, mutability, and exception behavior.

  3. Can an interface extend multiple interfaces?

    Answer: Yes. A declaration such as interface ManagedTask extends Runnable, AutoCloseable { } combines both contracts. A concrete implementation must satisfy their combined requirements.

    Multiple inheritance of interfaces is subject to compatibility rules. Inherited methods with incompatible return types can be illegal, and conflicting defaults may require an explicit resolution. Extending several interfaces does not mean inheriting several classes' instance state.


  4. How much of an interface must an abstract class implement?

    Answer: It may leave some or all abstract-method obligations unresolved. It can provide selected implementations and shared state for subclasses, or provide all required behavior while remaining abstract for design reasons.

    Abstract does not legalize an incompatible method declaration. For example, a protected implementation cannot satisfy a public interface method. A concrete descendant must supply all remaining valid implementations.

  5. Which keyword connects an interface to its superinterfaces?

    Answer: Extends. Interfaces do not have an implements clause. For example, interface NamedTask extends Runnable { String name(); } adds a name operation to the Runnable contract.

    Classes use implements to name their interfaces. Keeping these roles distinct makes a type hierarchy easier to read: extends establishes a superinterface relationship, while implements declares a class's supported interface types.

  6. Can an interface provide behavior even though it does not use implements?

    Answer: Yes. A default instance method can provide behavior inherited by implementing classes, and static and private methods can provide utilities and helpers. Interface inheritance still uses extends.

    A default method is not a constructor and does not add per-instance fields to the interface. A class method can take precedence over an interface default under the inheritance rules, and implementations must resolve applicable conflicts.


  7. How does class loading work in Java SE 25?

    Answer: Class loading locates or generates a class's binary definition and makes it available to the runtime. Linking and initialization are related but distinct stages. A class can be loaded without immediately running its static initialization code.

    The built-in loaders are the bootstrap, platform, and application/system loaders. The old description based on rt.jar and jre/lib/ext is obsolete: modern JDKs use modules, and the platform loader replaced the extension loader. Application loading depends on the class path, module configuration, and launch environment rather than only the CLASSPATH environment variable.

    ClassLoader normally uses parent delegation, but custom loaders and containers can use specialized policies. A class's runtime identity includes its binary name and defining loader; identically named classes from different loaders need not be assignment-compatible. Frameworks and application servers depend on these distinctions.

  8. How do return-type rules differ between overriding and overloading?

    Answer: An override needs a return type compatible with the overridden method: the same primitive type, the same void result, or a permitted reference return such as a covariant subtype. An overload with a distinct parameter signature need not share another overload's return type.

    Return type alone cannot distinguish two overloads. Even when different returns are legal, choose an API that remains understandable rather than making same-named operations return unrelated results without a clear reason.


  9. Can a subclass overload a method with a different return type?

    Answer: Yes, if it declares a legal distinct parameter signature. The inherited overload remains available according to the usual access rules.

    public class InheritedOverloads {
        static class Parent {
            int add(int left, int right) { return left + right; }
        }
        static class Child extends Parent {
            double add(double left, double middle, double right) {
                return left + middle + right;
            }
        }
        public static void main(String[] args) {
            Parent parent = new Child();
            Child child = new Child();
            System.out.println(parent.add(3, 5));
            System.out.println(child.add(2.5, 3.0, 5.0));
        }
    }

    The output is 8 and 10.5. The three-argument operation is an overload, not an override. It is not available through the Parent expression unless the expression is given a suitable more specific type.

  10. What must change to create an overloaded method?

    Answer: The parameter signature must be distinct under Java's rules. Changing the number or types of parameters can do this. Merely renaming a parameter, changing throws, or changing the return type cannot.

    Varargs and array syntax do not create separate signatures: work(String... values) and work(String[] values) cannot coexist as overloads. Generic erasure can likewise cause a name clash between declarations that appear different in source.

References: JLS: interfaces, JLS: methods, ClassLoader API, and JLS: loading, linking, and initialization.


SEMrush Software