- Which statement correctly describes the two field types?
Answer: value uses the type parameter, while history explicitly uses java.util.List.
When Java encounters a name in source code, it resolves it through a strict scoping hierarchy: local declarations (like type parameters) always shadow broader declarations (like imports). This question tests whether you understand that a generic type parameter name can legally shadow an imported class name within that class's scope.
In Box<List>, the identifier List is declared as a type parameter. Inside the class body, any bare use of List refers to that type parameter — not java.util.List. So private List value means value holds whatever type is passed as the type argument at instantiation. Meanwhile, private java.util.List<String> history uses the fully qualified name, which bypasses the shadowing entirely and refers directly to the interface in the java.util package. That's exactly what option D describes, making it correct.
Option A is wrong because the import does not "win" — the type parameter shadows it for bare uses of List within the class. Imports are effectively overridden by local scope declarations. Option B has the logic inverted: it claims value uses java.util.List, but value's type is the type parameter, not the imported class. Option C is wrong because Java does not prohibit naming a type parameter the same as an imported class — it's legal, just potentially confusing. The compiler resolves the ambiguity through scoping rules, not by rejecting the code.
As a study tip, remember: local scope always wins in Java. Type parameters, local variables, and method parameters shadow outer declarations. When you see a fully qualified name like java.util.List, that's a deliberate escape hatch to reach past shadowing.
- At compile time, which type does the simple name
List denote? Answer: It denotes java.awt.List because its single-type import takes precedence over the wildcard import.
When Java resolves a simple type name like List, the compiler follows a strict precedence hierarchy for imports, and understanding that hierarchy is the key to this question.
A single-type import (e.g., import java.awt.List) always takes precedence over a wildcard import (e.g., import java.util.*). This is a deliberate design choice in Java: when you explicitly name a type in an import, the compiler treats that as your intentional choice and honors it over any on-demand wildcard imports. So in this code, List unambiguously resolves to java.awt.List — making B the correct answer.
A is wrong because import declaration order is completely irrelevant in Java. The compiler doesn't read imports sequentially and let the first one "win." C would be correct if two single-type imports brought in different List types — that would genuinely create an ambiguity error. But here, only one single-type import exists (java.awt.List), so there is no ambiguity; the wildcard simply loses. D is a fabrication — java.lang.List doesn't exist as a type, and while java.lang types do take precedence over imports, that rule applies only to types actually in java.lang.
The critical study tip here: memorize the Java import precedence order — **explicit single-type imports beat wildcards, and java.lang types beat both**. A common trap on Java exams is making you think two competing imports always cause ambiguity. They only do when both are single-type imports naming the same simple name.
- Which revision resolves the conflict while preserving the intended types:
java.util.Timer for backgroundTimer and javax.swing.Timer for interfaceTimer? Answer: Remove the Swing import, keep the utility import, and declare interfaceTimer as javax.swing.Timer.
When two classes share the same simple name, Java can only resolve an ambiguous import if you give it unambiguous instructions — either by dropping one import or by using a fully-qualified class name (FQCN) directly in the code. This question tests whether you understand how to eliminate that ambiguity while keeping both types in play.
The cleanest solution, and why B is correct, is to remove the javax.swing.Timer import and keep only import java.util.Timer. With that single import active, writing Timer backgroundTimer unambiguously refers to java.util.Timer. For interfaceTimer, you write the FQCN inline: javax.swing.Timer interfaceTimer. No conflict exists because only one Timer name is imported — the other is always referenced explicitly.
A sounds tempting but is backwards. If you keep both imports, the compiler still sees ambiguity when it encounters the bare name Timer for backgroundTimer. Qualifying only interfaceTimer doesn't resolve what Timer means for the other field — the conflict remains.
C is a common misconception: wildcard imports (java.util.* and javax.swing.*) do not resolve name conflicts. When both wildcards are present, Timer is still ambiguous between the two packages, and the compiler will refuse to compile.
D would fail immediately. Without any imports, you cannot use the simple name Timer at all — the compiler won't know which class you mean, and unqualified names without imports produce compilation errors.
Study tip: Whenever two classes share a simple name, remember the formula: import the one you use more often, and write the full package path inline for the other.
- Which single-type import should be added so that
TimeUnit is resolved correctly? Answer: import java.util.concurrent.TimeUnit;
When working with Java imports, you need to know both the class name and the exact package it lives in. TimeUnit is an enum used for time-based delays and scheduling — it is not part of java.util, despite what the existing wildcard import might suggest.
TimeUnit belongs to the java.util.concurrent package, which is a separate package dedicated to concurrency utilities. A single-type import names one specific class in full: import java.util.concurrent.TimeUnit; — that's exactly what B does, giving the compiler an unambiguous path to resolve the TimeUnit identifier. This is the correct answer.
A is wrong because TimeUnit does not exist in java.util. Even though java.util.* is already imported, it doesn't cover TimeUnit — the wildcard only imports classes within that exact package, not sub-packages. Writing import java.util.TimeUnit; references a class that simply doesn't exist there, causing a compile error.
C (import java.util.concurrent.*;) would actually work at runtime, but the question specifically asks for a single-type import. A wildcard (*) is called an on-demand import, not a single-type import — so C is the wrong import style for what's being asked, regardless of correctness.
D (import java.util.concurrent.TimeUnit.SECONDS) attempts to import an enum constant, not the class itself. Java imports resolve type names, not individual constants — you can't import a field or enum value this way.
Study tip: Memorize that java.util and java.util.concurrent are completely separate packages — Java does not automatically import sub-packages. When you see concurrency types like TimeUnit, ExecutorService, or Future, think java.util.concurrent.
- Which import declaration is required for this file to compile?
Answer: import java.util.ArrayList;
When you see a Java import question, focus on one key rule: you only need to import classes that come from outside the current package and outside java.lang.
ArrayList lives in java.util, which is neither the current package nor java.lang, so it must be explicitly imported. That makes C — import java.util.ArrayList; — the required import for this file to compile.
Here's why the other options miss the mark. A is unnecessary because java.lang is automatically imported by the Java compiler for every file — String, Integer, Object, and other java.lang types are always available without an explicit import. B might seem necessary since Item is used as a field type, but Item is declared in the same package (inventory), and classes within the same package can see each other without any import statement. D is simply invalid syntax — you can't chain a class name onto another class in an import path like that. ArrayList.Item isn't a real type in java.util; the import statement would cause a compile error.
A useful rule of thumb: ask yourself three questions about each type used in a file — Is it from java.lang? Is it in the same package? Did I write a full import for it? If the answer to all three is "no," the file won't compile. On import questions, the most common trap is forgetting that same-package classes and java.lang classes never need imports, while standard library classes like ArrayList, HashMap, or Scanner almost always do.
- Which change is necessary for
Main.java to compile? Answer: Declare Ledger as public in Ledger.java, keeping its constructor accessible.
When a class is defined without the public modifier in Java, it has package-private (default) access. This means the class is only visible to other classes within the same package. Even if you import it from another package, the compiler will refuse access because the class itself isn't visible outside its package.
That's exactly the problem here. Ledger is declared as class Ledger — no public keyword — so it's package-private to the library package. Main lives in the client package, meaning it has no visibility into Ledger at all, regardless of the import statement. The fix is to declare Ledger as public class Ledger, which makes it accessible across packages. The constructor is already public, so no additional changes are needed there. This makes C the correct answer.
A is wrong because switching from a single-type import to a wildcard import (import library.*) changes nothing about access control. Wildcard imports are purely a convenience shorthand — they don't grant any additional permissions.
B is wrong for the same underlying reason. Writing the fully-qualified name library.Ledger instead of using an import is another shorthand alternative, but it still doesn't bypass access control. If Ledger is package-private, you can't access it from outside library by any naming syntax.
D is wrong because import statement placement (above or below class declarations) has no effect on access or compilation order. Imports must appear before the class declaration anyway — moving them after would itself be a syntax error.
Study tip: Always remember that access modifiers on the class itself are the first gate — an import only tells the compiler where to find a class, not whether you're allowed to use it.
- Which statement correctly describes how the two
Date references are resolved? Answer: The code compiles; cutoff uses java.sql.Date, while epoch uses java.util.Date.
When Java resolves class names, it follows a strict priority order: explicit (single-type) imports beat wildcard imports, and fully qualified names always resolve unambiguously regardless of any imports present. Keeping this hierarchy in mind unlocks this question immediately.
Here, import java.sql.Date is a single-type import, so any bare reference to Date in this file resolves to java.sql.Date — that's what cutoff uses. For epoch, the code doesn't use a bare name at all; it spells out java.util.Date in full, which bypasses the import system entirely and pinpoints exactly which class is meant. Both fields are perfectly legal, and the file compiles without error, making A the correct answer.
B is wrong because wildcard imports (java.util.*) do not take priority over single-type imports — it's the reverse. A single-type import always wins over a wildcard, regardless of the order they appear in the source file.
C reflects a common myth: importing two packages that both contain a class with the same name is not automatically a compile error. The conflict only surfaces if you use the bare name Date while both packages are wildcard-imported (with no single-type import to break the tie). Here, one import is explicit, so there's no ambiguity.
D is simply false. Fully qualified class names are always valid in Java. A wildcard import doesn't prevent or override a fully qualified reference — the two coexist peacefully.
Study tip: Memorize the resolution order — fully qualified name → single-type import → wildcard import. This chain explains nearly every "ambiguous import" question you'll encounter on the Java exam.
- What is the compile-time result?
Answer: The code compiles because Color resolves to java.awt.Color and List is fully qualified.
When you see wildcard imports in Java, the key question is whether the compiler can unambiguously resolve each type name — and the rules for this are more nuanced than most students expect.
Java's import resolution follows a clear priority system: a fully qualified type name always wins, regardless of any wildcard imports in scope. In this code, Color is referenced without qualification, so the compiler checks the wildcard imports (java.awt.* and java.util.*) to resolve it. Since Color exists only in java.awt, it resolves cleanly to java.awt.Color. Meanwhile, java.util.List<String> is written as a fully qualified name directly in the field declaration, so the wildcard import for java.util is irrelevant to its resolution entirely. The code compiles without issue, making A correct.
B is wrong because wildcard imports do not automatically make everything ambiguous — they only cause a compile error when a specific name exists in multiple imported packages simultaneously. Two wildcards coexisting is perfectly legal.
C reflects a common misconception: you can absolutely use a fully qualified class name even when its package is already wildcard-imported. The two are not in conflict; the explicit qualification simply takes precedence.
D would be correct if Color existed in both java.awt and java.util, but it doesn't — Color is unique to java.awt, so no ambiguity arises.
As a study tip, remember that ambiguity errors only occur when a simple name matches types in two or more imported packages. Fully qualifying a name is always a safe escape hatch.
- Which additional import is needed to make the class compile without changing the field declaration?
Answer: import java.util.concurrent.TimeUnit;
When working with imports in Java, it helps to remember that static imports and regular imports serve different but complementary purposes — and you often need both.
A static import like import static java.util.concurrent.TimeUnit.SECONDS; brings the constant SECONDS into scope so you can use it unqualified. However, it does not bring the type TimeUnit into scope. In the field declaration TimeUnit unit = SECONDS;, the compiler sees two distinct references: the type name TimeUnit and the constant SECONDS. The static import handles SECONDS, but you still need a regular import to resolve the type TimeUnit. That's why D — import java.util.concurrent.TimeUnit; — is the correct additional import. It gives the compiler the type information it needs for the field declaration.
Looking at the distractors: A uses regular import syntax (import) but targets a specific member (TimeUnit.SECONDS), which is invalid — regular imports can only target classes or packages, not individual members. B is syntactically nonsensical; you cannot chain a wildcard with a class name like *.TimeUnit in an import statement. C attempts a static import of TimeUnit itself, but static imports apply to members (fields, methods) of a class, not to the class type itself — so import static java.util.concurrent.TimeUnit; won't compile.
A good rule of thumb: whenever you use a static import for a member of a class, ask yourself whether you also reference the class name directly in your code. If you do, you'll need a separate regular import for the class type.
- Which import allows the simple name
Entry to be used exactly as shown? Answer: import java.util.Map.Entry;
When working with nested types in Java, the import statement must mirror the exact package-and-class hierarchy of what you're importing. Map.Entry is not a standalone class in java.util — it's a **static nested interface defined inside Map**. That nesting matters for imports.
To use Entry as a simple name (without writing Map.Entry every time), you need to import it via its full nested path: java.util.Map.Entry. This is exactly what A does, making it the correct answer. After this import, the compiler knows Entry refers to java.util.Map.Entry, so Entry<String, Integer> compiles cleanly.
B (import java.util.Entry) is wrong because there is no top-level class called Entry directly in java.util. This import would cause a compile-time error — the package path doesn't include Map as a stepping stone, which is required.
C (import java.util.MapEntry) is wrong for a similar reason: MapEntry doesn't exist anywhere in the standard library. This is a fabricated class name that combines the two parts of Map.Entry incorrectly.
D (import java.util.Map.Entry.*) attempts a wildcard import of everything inside Entry. While wildcard imports are valid in Java, Entry itself is an interface with no nested members worth importing this way — and crucially, this import still doesn't bring Entry itself into scope as a simple name. You'd still need to write Map.Entry in your code.
A useful tip: whenever you want to use a nested type by its simple name, the import path must include every enclosing class, just like a file path must include every parent folder.
