Chapter 7: Beyond Classes Flashcards
Anonymous classes can be declared static?
False
Anonymous classes always have an implicit reference to their enclosing class?
True
Anonymous classes are a type of nested class that can be static?
False
Since anonymous classes cannot be static, they must be associated with an instance of the enclosing class?
True
The keyword “static” can be used when defining anonymous classes?
False
Interface variables in Java are public, static, and final by default.
True
Interfaces in Java are required to define at least one method.
False: Interfaces can be empty, and the compiler automatically treats them as abstract even without method definitions.
An interface can be instantiated directly
False: Interfaces cannot be instantiated because they only provide method signatures without implementations.
Interfaces are implicitly considered abstract, even without the abstract keyword.
True
Interfaces can be marked as final in Java.
False: Interfaces cannot be final, as final would prevent implementation, defeating their purpose.
In Java 17, if a class inherits two interfaces with the same default method signature, it must override the method. (True/False) If false, why?
True
A class can inherit conflicting default methods from multiple interfaces without requiring an override. (True/False) If false, why?
False – The compiler enforces overriding to resolve ambiguity in method implementation.
The syntax to access an inherited default method is <interface>.super.<method>. (True/False) If false, why?</method></interface>
True
In Java 17, a class can directly call a default method from an interface without specifying the interface name. (True/False) If false, why?
False – It must use <interface>.super.<method> to specify the source interface.</method></interface>
Default methods in interfaces cannot be overridden by implementing classes. (True/False) If false, why?
False – Implementing classes can override default methods to provide custom behavior.
An interface can extend multiple interfaces using the extends keyword.
True
A class can extend multiple interfaces.
False – A class implements interfaces, but it can extend only one class.
Interfaces are initialized as part of a class hierarchy.
False – Interfaces do not have constructors and are not part of instance initialization.
A class can extend an interface.
False – A class can only implement an interface, not extend it.
An interface can implement another interface.
False – An interface can extend another interface, but it cannot implement one.
A method that properly overrides inherited methods can use covariant return types.
True
Interfaces are implicitly abstract.
True
Interface variables are implicitly public, static, and final.
True
If a method or variable is marked with a conflicting modifier, the compiler applies the public modifier without conflict.
The compiler detects a conflict and generates an error.
Both abstract classes and interfaces use implicit modifiers.
False – Only interfaces use implicit modifiers; abstract classes do not. If false, why?
A constant variable in an interface is implicitly public static final. If false, why?
True
An abstract method in an interface is implicitly private abstract. If false, why?
False – It is implicitly public abstract.
A default method in an interface must be marked with the default keyword and have a method body. If false, why?
True
A static method in an interface is implicitly private static. If false, why?
False – It is implicitly public static.
A private method in an interface can have an abstract modifier. If false, why?
False – Private methods must have a method body, so they cannot be abstract.
A private static method in an interface does not require a method body. If false, why?
False – All private methods must have a method body.
A method marked protected in an interface is allowed. If false, why?
False – Interfaces do not support protected methods because they cannot be extended like classes.
A method in an interface without an access modifier is implicitly package-private. If false, why?
False – It is implicitly public, to maintain backward compatibility.
A default method in an interface can be marked final. If false, why?
False – Default methods cannot be final because they are meant to be overridden.
A class must override a default method if it inherits two default methods with the same signature. If false, why?
True
A class implementing an interface must override all its default methods. If false, why?
False – Default methods are optional to override; they have a provided implementation.
An interface can contain both static and private methods. If false, why?
True
A class implementing multiple interfaces with the same default method must override the method to resolve ambiguity. If false, why?
True
A default method in an interface behaves only like an instance method, not like a static method. If false, why?
False – It exhibits properties of both static and instance methods.
The super keyword is used with interface names to indicate following instance inheritance. If false, why?
True
Interfaces can declare static methods without using the static keyword. If false, why?
False – A static method must be explicitly marked with static.
Static methods in interfaces are always private by default. If false, why?
False – They are implicitly public if no access modifier is provided.
Static methods in interfaces cannot be inherited by implementing classes. If false, why?
True
An interface can define a static method without a method body. If false, why?
False – A static method must always have a method body.
Static methods in interfaces can be marked as final. If false, why?
False – Static methods in interfaces cannot be final.
Private static interface methods can be called by any method within the interface. If false, why?
True
A private non-static interface method can be called by both static and non-static methods within the interface. If false, why?
False – It can only be called by non-static methods.
Private interface methods were introduced primarily to enhance encapsulation and reduce code duplication. If false, why?
True
A private interface method can be called directly from a class implementing the interface. If false, why?
False – Private methods in interfaces cannot be accessed by implementing classes.
A class can override a private method of an interface. If false, why?
False – Private methods in interfaces are not inherited, so they cannot be overridden.
An interface can have both default and static methods. If false, why?
True
A private interface method can be marked as abstract. If false, why?
False – Private methods must have a method body, so they cannot be abstract.
A private static interface method can be accessed by another private static method within the same interface. If false, why?
True
Default and private non-static methods in an interface can access abstract methods. If false, why?
True.
Abstract methods in an interface require an instance of the interface for access. If false, why?
True.
Constant variables in an interface can be accessed without an instance. If false, why?
True.
Private static methods in an interface are accessible from other static methods within the same interface. If false, why?
True
Default methods in an interface are accessible by classes implementing the interface. If false, why?
True.
Static methods in an interface require the interface name for access. If false, why?
True
Abstract methods in an interface are accessible within the interface itself. If false, why?
Abstract methods cannot have a body and are not accessible within the interface. (False)
Private methods in an interface are accessible from implementing classes. If false, why?
Private methods are only accessible within the interface itself. (False)
You can extend an enum to add more values. If false, why?
Enums are final by design and cannot be extended. (False)
Enum values can be dynamically modified at runtime. If false, why?
Enum values are constants and immutable. (False)
The semicolon at the end of a simple enum’s value list is required. If false, why? )
It is optional unless additional code follows. (False
Enums do not offer type safety compared to using constants. If false, why?
Enums are type-safe, unlike numeric or string constants. (False)
An enum provides a values() method to get an array of all of the values. You can use this like any normal array, including in a for-each loop.
True
Each enum value has a corresponding int value, and the values are listed in the order in which they are declared.
True
You can’t compare an int and an enum value directly since an enum is a type, like a Java class, and not a primitive int.
True
The valueOf() method allows retrieving an enum value from a String, and the String must match the enum value exactly.
True
Enums can be used in both switch statements and switch expressions.
True
All enum constructors are implicitly private, and using public or protected in the constructor will result in a compilation error
True
Enum values can be modified after they are created.
Enum values should be immutable since they are shared in the JVM, and modifying them is a poor practice.
Enum constructors can be explicitly declared as public or protected.
Enum constructors are always private (implicitly or explicitly); public or protected modifiers cause a compilation error.
Enums must contain only a list of values and cannot have instance variables or methods.
Enums can have instance variables and methods, making them more complex if needed.
The order of enum values can be changed at runtime.
Enum values are assigned at compile-time and cannot be reordered at runtime.
You can extend an enum in Java.
Enums are implicitly final, meaning they cannot be subclassed.
In an enum, instance variables are shared across instances of the enum.
Each enum value is a singleton, so instance variables are specific to each enum constant.
A sealed class is a class that restricts which other classes may directly extend it.
True
A sealed class declares a list of classes that can extend it, while the subclasses declare that they extend the sealed class.
True
Sealed classes are commonly declared with the abstract modifier, although this is certainly not required.
True
Every class that directly extends a sealed class must specify exactly one of the following three modifiers: final, sealed, or non-sealed.
True
Besides classes, interfaces can also be sealed, and many of the same rules apply.
True
The permits keyword is mandatory when declaring a sealed class.
It is optional if all subclasses are in the same file or nested.
A non-sealed class cannot be extended by other classes.
(A non-sealed class removes restrictions and allows unrestricted extension.)
A sealed class can be extended by any class in the same package.
(Only explicitly permitted subclasses can extend a sealed class.)
Sealed interfaces must have their permitted classes/interfaces listed using permits.
(The permits clause is optional in certain conditions.)
The permits clause must always explicitly list all allowed subclasses.
(It can be omitted if subclasses are declared in the same file or are nested.)
A final interface can extend a sealed interface.
(Interfaces cannot be marked final; they can only be sealed or non-sealed.)
Sealed interfaces and their implementations must be in different packages.
(They must be in the same package or module.)
A sealed class and its permitted subclasses must be in different files.
(They can be in the same file or even be nested.)
The permits clause must always be used for nested subclasses.
(It can be omitted if all subclasses are declared within the same sealed class.)
Sealed classes are declared with the sealed and permits modifiers.
True.
Sealed classes must always be declared in a named module along with their direct subclasse
They must be in the same package or module, but not necessarily a named module
Direct subclasses of a sealed class can be marked as abstract.
(False – They must be marked final, sealed, or non-sealed.)
The permits clause is optional if the sealed class and its direct subclasses are in the same file.
True
A sealed interface can only limit the classes that implement it, not the interfaces that extend it.
(False – It can limit both implementing classes and extending interfaces.)
A POJO requires a no-arg constructor like a JavaBean.
(False – A POJO does not require a no-arg constructor.)
Encapsulation prevents modifying methods in a class.
(False – Encapsulation restricts direct access to instance variables but allows method modifications.)
Encapsulation ensures that method behavior cannot change in the future.
(False – Methods can be modified while maintaining the same signatures.)
Records allow defining explicit setter methods.
(False – Record fields are implicitly final, so setters are not allowed.)
The constructor of a record allows parameters in any order.
(False – It follows the same order as the record declaration.)
The equals() method of a record allows customization without overriding it.
(False – Customization requires explicitly overriding equals().)
Records automatically generate a toString() method that includes all fields.
True
The final modifier prevents a class from being extended.
True
Java allows a class to have multiple direct parent classes.
(False – Java supports single inheritance, but a class can implement multiple interfaces.)
A class in Java can extend multiple classes at the same time.
(False – Java does not allow multiple inheritance for classes.)
Abstract classes are an exception to Java’s single inheritance rule.
(False – Java’s exception to single inheritance is interfaces, not abstract classes.)
A subclass in Java can inherit directly from two different superclasses.
(False – A subclass can have only one direct parent class.)
If a class has a parent, it cannot have multiple child classes.
(False – Single inheritance does not prevent a parent class from having multiple children.)
All Java classes implicitly inherit from java.lang.Object.
True
Primitive types like int and boolean inherit from Object.
(False – Primitive types are not classes and do not inherit from Object.)
If a class extends another, Java implicitly adds extends Object.
(False – Java does not implicitly extend Object if a class already extends another.)
If a class has no explicit superclass, Java automatically extends java.lang.Object.
(True)
The equals() method in Java is always useful for comparing objects.
(False – The equals() method must be overridden for meaningful comparisons.)
By default, toString() in Java provides a human-readable description of an object.
(False – The default toString() returns a memory reference unless overridden.)
Java allows a class to extend multiple classes using the extends keyword.
(False – A class can extend only one class but implement multiple interfaces.)
The inheritance structure of every Java class ends with null.
(False – The inheritance structure always ends with Object, not null.)
Java automatically calls super.toString() when printing an object.
(False – super.toString() is not automatically called unless explicitly implemented.)
Object is the only class in Java that does not have a parent.
True
All permitted subtypes of a sealed type must belong to the same package.
False – They can belong to the same package or the same named module.
A sealed class in a named module can have permitted subtypes from different modules.
False – All permitted subtypes must belong to the same module as the sealed class.
If a sealed class is in an unnamed module, all its permitted subtypes must be in the same package.
✅ True – This is required to avoid a compile-time error.
A sealed class in a named module can permit subtypes from different packages as long as they are in the same module.
✅ True – The package restriction applies only to unnamed modules.
A permitted subclass of a sealed class must always be in the same package.
❌ False – This is only true for unnamed modules. For named modules, the permitted subclass can be in a different package as long as it is in the same module.
The permits clause of a sealed class is optional if all permitted subclasses are declared in the same file.
✅ True – If all subclasses are declared in the same compilation unit, Java can infer the permitted subclasses.
If a sealed class is declared in an unnamed module, it can permit subclasses from different modules.
❌ False – Unnamed modules don’t allow cross-module subclassing.
If a sealed class does not specify permits, it becomes non-sealed automatically.
❌ False – It only means Java will infer the permitted subclasses from the same compilation unit.
A sealed class in a named module can only have subclasses that are also in named modules.
✅ True – The subclasses must be in the same named module.
If a sealed class and its permitted subclasses are in different named modules, Java will generate a compile-time error.
✅ True – A named module cannot have permitted subclasses in another module.
Records don’t have setters because every field is inherently final and cannot be modified after construction.
(✅ True)
Records are implicitly final, meaning they cannot be extended.
(✅ True)
A record can implement a regular or sealed interface if it implements all the abstract methods.
(✅ True)
Records promote immutability, making them inherently thread-safe and suitable for concurrent frameworks.
(✅ True)
If a record has a constructor with the same parameter list as the automatically generated one, the compiler does not insert its own constructor.
(✅ True)
Records allow fields to be modified after object creation.
(❌ False – Fields in records are final.)
Records must explicitly declare the final keyword to prevent extension.
(❌ False – They are implicitly final.)
Records can extend other records or classes like normal Java classes.
(❌ False – They cannot extend any class.)
Records cannot have constructors with validation logic.
(❌ False – They can include validation logic, as shown in the example.)
Records eliminate all boilerplate code, even when declaring custom constructors.
(❌ False – Declaring a constructor with many fields still introduces boilerplate code.)
True/False: A Java record automatically provides a canonical constructor if no constructor is explicitly declared.
True – If no constructor is defined, Java generates a default canonical constructor.
A compact constructor in a record must explicitly declare parameter names.
Compact constructors omit explicit parameter declarations; the parameters are inferred from the record components.
A record in Java can have multiple compact constructors.
False – A record can have only one compact constructor
A compact constructor in a record allows performing validation or transformation of input parameters before assigning values to fields.
True – Compact constructors enable adding logic like validation before record fields are assigned.
If a record has a compact constructor, the compiler still generates a default canonical constructor separately.
The compact constructor replaces the canonical constructor; the compiler does not generate an additional one.
The compact constructor in a record does not require explicit assignment of values to record fields.
True – Java automatically assigns values to record components in a compact constructor.
A record in Java cannot have additional instance fields beyond the components defined in its declaration.
True – Records only store the fields defined in the record header; no extra instance fields are allowed.
The canonical constructor in a record must always call super() explicitly.
False – The compiler automatically inserts super() where necessary, so it is not required to be explicitly called.
A record constructor can define extra fields not listed in the record header.
False – Records cannot define additional instance fields beyond those in the record header.
The primary purpose of a compact constructor in a record is to simplify code by allowing logic such as validation without explicitly listing parameters.
True – Compact constructors help keep code clean by allowing logic like validation without requiring explicit parameter declarations.
A record in Java can have overloaded constructors that take a completely different list of parameters.
✅
A static nested class is a static type defined at the member level of a class.
✅
Compact constructors in a record are declared without curly braces {} to distinguish them from normal constructors.
❌ (Compact constructors require curly braces like normal constructors.)
A compact constructor in a record can modify both constructor parameters and instance fields.
❌ (Compact constructors can modify parameters but not instance fields.)
Instance initializers are supported in records to allow additional initialization logic outside constructors.
❌ (Records do not support instance initializers; all initialization must be done in a constructor.)
A record can define additional instance fields outside the record declaration as long as they are private.
❌ (Records do not allow extra instance fields outside the declared components.)
Anonymous classes are a special case of nested classes that are always static.
❌ (Anonymous classes are always inner classes and cannot be static.)
Overloaded constructors in a record must always call the primary constructor using this().
❌ (Overloaded constructors do not have to call the primary constructor.)
A local class is defined at the member level of a class, similar to inner and static nested classes.
❌ (Local classes are defined within a method body, not at the member level.)
A nested class in Java can only be a static nested class or an inner class, with no other variations.
❌ (There are four types: inner class, static nested class, local class, and anonymous class.)
The Java compiler will execute the full constructor of a record after executing the compact constructor.
❌ (The compact constructor is the full constructor; there is no separate execution.)
