- Which Javadoc tag section correctly documents both the type parameter and the ordinary parameter?
Answer: `@param <T> the list's element type
@param items the list to inspect
@return the first element
@throws IllegalArgumentException if items is empty`
When documenting generic methods in Javadoc, you need to know one critical syntax rule: type parameters get their own special @param format using angle brackets, written as @param <T>, while regular parameters use the standard @param paramName syntax. This distinction is easy to overlook but frequently tested.
B is correct because it follows both conventions precisely. The type parameter T is documented as @param <T> the list's element type — note the angle brackets wrapping T — and the regular parameter uses @param items the list to inspect. The @return and @throws tags are also accurate: the method returns the first element and throws IllegalArgumentException when the list is empty, which matches the code exactly.
A fails because it documents the type parameter as @param T without angle brackets. This treats T as if it were a regular method parameter named T, which is incorrect Javadoc syntax for type parameters.
C makes two mistakes: it misuses @param <T> by describing it as "the first list element" (that's what @return should describe), and it invents a nonexistent parameter tag @param List<T>. The actual parameter name is items, not List<T>. It also incorrectly says the exception triggers when items is null — the code throws on an empty list.
D invents a combined tag @param items<T>, which is not valid Javadoc syntax at all. It also falsely states the exception fires when the list has one element — it fires when the list is empty.
Your memory aid: type parameters wear "angle-bracket hats" — @param <T> — while regular parameters go bare.
- Which replacement correctly creates an inline link to the one-parameter overload?
Answer: For text input, use {@link #parse(String)}.
When writing Javadoc, you have two ways to reference other methods: the block tag @see and the inline tag {@link}. The key distinction is that {@link} embeds a clickable hyperlink within a sentence, while @see creates a separate "See Also" section at the bottom of the documentation — it cannot be dropped into the middle of a sentence as inline text.
The correct way to specify a method reference in Javadoc is to use the method name followed by its parameter types only (no parameter names), enclosed in parentheses. So {@link #parse(String)} correctly targets the one-parameter overload and embeds it inline within the sentence — making D the right answer.
Looking at why the others fail: A uses {@link #parse()}, which has the correct inline tag syntax but references the zero-parameter overload, not the parse(String text) method — so it links to the wrong method entirely. B uses @see #parse(String), which has the correct method signature but uses the block tag @see instead of {@link}. Dropping a block tag mid-sentence produces broken Javadoc output, not an inline link. C uses {@link #parse(String text)}, which includes the parameter name (text) alongside the type — Javadoc method references only accept types in the signature, not names, so this would fail to resolve the link correctly.
A useful rule of thumb: in Javadoc method references, types only, no names — and use {@link ...} when you want the reference embedded in prose, @see only when you want a standalone "See Also" entry.
- Which exception documentation best describes the method's public behavior?
Answer: `@throws IOException if an input/output error occurs
@throws IllegalArgumentException if path is null`
When documenting exceptions in Java, your goal is to describe the public contract of a method — what callers should expect — not internal implementation details. For each exception type, the Javadoc should accurately reflect when that specific exception is thrown and why.
Looking at the method, two exceptions can escape to the caller: IllegalArgumentException (thrown explicitly when path is null) and IOException (declared in the throws clause and propagated from Files.newBufferedReader and readLine()). Answer A captures both exceptions correctly, pairing each with its actual trigger condition. This is exactly what good @throws documentation looks like — precise, accurate, and matched to the real behavior.
B is wrong because it collapses two distinct exception types into a single vague @throws Exception, which obscures the difference between a programming error (null path) and an I/O failure. Callers need to know which exception to catch and under what conditions. C swaps the conditions entirely — it claims IOException is thrown for a null path (wrong; that throws IllegalArgumentException) and that IllegalArgumentException is thrown when no lines exist (wrong; readLine() simply returns null in that case, throwing nothing). D is wrong because it ignores IllegalArgumentException entirely, claiming unchecked exceptions are never documented. While unchecked exceptions can be omitted, they should be documented when they represent meaningful precondition violations, as they do here.
A useful rule of thumb: match each @throws tag to the specific exception class that actually escapes the method, with a condition that directly explains when the caller will see it.
- Which sentence meets both formatting requirements?
Answer: Returns a value of the form {@code <T>}.
When writing Javadoc, you frequently need to display text that contains angle brackets like <T>, but raw angle brackets in HTML are interpreted as tag delimiters — they'll either disappear or break your documentation rendering. Javadoc gives you two inline tag tools to handle this: {@literal} and {@code}.
{@code} does double duty: it escapes HTML special characters (including < and >) and renders the content in a monospace, code-style font. So {@code <T>} displays the literal text <T> in code formatting — satisfying both requirements in the question. That makes C the correct answer.
Here's why each other option falls short. A simply writes <T> as raw HTML, which most browsers and Javadoc renderers will interpret as an unknown tag and strip entirely, so <T> never appears in the output. B uses {@literal}, which does escape the angle brackets so <T> appears literally — but {@literal} renders in plain text, not code-style monospace formatting. It meets the "literal" requirement but misses the "code formatting" requirement. D wraps <T> in <code> HTML tags, which handles the font styling, but the raw <T> inside is still unescaped HTML, meaning it gets swallowed as an unknown tag rather than displayed.
A useful rule of thumb: prefer {@code} over {@literal} whenever you're documenting code tokens, generics, or operators — it handles both escaping and formatting in one tag, while {@literal} only escapes without styling.
- Which
@param entry correctly documents the variable-arity parameter? Answer: @param values the values whose sum is returned
When writing Javadoc comments, the @param tag follows a strict syntax: @param parameterName description. The key word here is parameter name — Javadoc uses the name as it appears in the method signature, nothing more, nothing less.
For a variable-arity (varargs) method like total(int... values), the parameter name is simply values. That makes C the correct choice: @param values the values whose sum is returned matches exactly how Javadoc expects it — just the name, followed by the description.
Here's why the other options miss the mark. A uses int... instead of the parameter name — it's using the type rather than the identifier. Javadoc doesn't accept type information in the @param tag; type information lives in the method signature itself. B appends ... to the parameter name, writing values..., which might seem logical since the parameter is declared with ..., but Javadoc does not include the ellipsis in the tag — again, only the bare name. D uses value (singular), which is the loop variable inside the method body, not the actual parameter name. Documenting an internal loop variable with @param is incorrect because @param is strictly for method parameters, not implementation details.
A useful rule of thumb: whatever identifier appears directly before the ... in a varargs declaration is your parameter name. Document that exact name with @param, and let the description explain the "many values" behavior in plain language rather than through special syntax.
- Which opening sentence provides the strongest contract-focused summary for this method's Javadoc?
Answer: Returns a locale-independent lowercase form with leading and trailing whitespace removed.
When writing Javadoc, your goal is to describe what a method does for the caller, not how it does it internally. A strong opening sentence communicates the method's contract: its inputs, outputs, and observable behavior — all at a semantic level.
Option D nails this. It tells the caller exactly what they receive back ("a locale-independent lowercase form") and what transformation was applied ("leading and trailing whitespace removed"). It describes the result, which is what callers actually care about. The mention of locale-independence is especially important because it signals predictable, consistent behavior across different runtime environments — a meaningful guarantee, not just an implementation detail.
Option A is the most common trap: it describes implementation steps ("calls trim and then calls toLowerCase") rather than behavior. Javadoc should hide implementation details, not expose them. If you later refactor the method, this sentence would become a lie.
Option B is vague to the point of being useless. "Processes a string by using several methods" could describe almost any method in existence. Good Javadoc is precise and specific.
Option C contains a factual error that reflects a deeper misconception: Java strings are immutable. name is never modified; a new String is returned. Saying the method "modifies name" and "changes its stored characters" is simply wrong about how Java works.
As a study strategy, remember this rule: Javadoc describes contracts, not code. When evaluating a summary sentence, ask yourself — "Could a caller use this without reading the source?" If yes, you likely have the right answer.
- Which Javadoc tag section is appropriate for this method?
Answer: `@param level the new level, from 0 through 10
@throws IllegalArgumentException if level is outside the range`
When writing Javadoc for a method, you need to match your tags precisely to what the method actually does — its parameters, return value, and exceptions. Think of Javadoc as a contract: every tag must reflect reality, nothing more and nothing less.
The setLevel method accepts one parameter (level), returns nothing (void), and throws an IllegalArgumentException if the value is out of range. That maps perfectly to B: a @param tag describing the valid input range and a @throws tag naming the exact exception with an accurate condition. No @return tag is needed because void methods don't return a value — Javadoc convention is simply to omit it.
A adds a @return tag claiming the method returns "the level stored in this object," which is false — the method is void. Fabricating a return description would mislead anyone reading the API.
C makes two mistakes: it uses @param this.level, but @param should reference the parameter name (level), not the field it assigns to. Additionally, it says the exception fires "if the current level is outside the range," which misrepresents the logic — the exception is based on the incoming parameter, not any pre-existing value.
D includes a @return nothing after the field is updated, which again is incorrect convention — you simply omit @return for void methods. It also changes the exception type to @throws RuntimeException, which is imprecise; you should always document the most specific exception type thrown.
A good study tip: for any method, run through three questions — Does it take parameters? Does it return a value? Does it throw exceptions? Only include Javadoc tags for what actually applies.
- Which
@return description most completely states the method's result contract? Answer: @return the first index of target in text, or -1 when target is absent
When writing Javadoc, your @return tag must accurately describe what value is returned and what it means — including both the success case and any special sentinel values. For a method that wraps String.indexOf(char), you need to know exactly what that method does: it returns the index of the first occurrence of the character, or -1 if the character is not found.
That makes B the correct answer. It captures both key facts precisely — "first index" (since indexOf stops at the first match) and "-1 when absent" (the actual sentinel value indexOf uses). This is a complete and accurate contract description.
A is wrong in two ways: it omits the word "first," which matters because there could be multiple occurrences, and it states the absent-case return value is 0 — but 0 is actually a valid index (the first character position). Returning 0 for "not found" would be ambiguous and is simply not what indexOf does.
C describes a completely different method — something that counts occurrences rather than locates them. The -1 for an empty string is also fabricated; nothing in the code behaves this way. This distracts students who confuse indexOf with a frequency-counting method.
D confuses the return type with the search target. The method returns an int index, not a char. Returning target or a null character would require a completely different signature and purpose.
A useful rule of thumb: always verify your @return description against the actual Java API behavior, paying special attention to edge-case return values like -1, null, or 0, since those are the most common sources of documentation errors.
- Which set of Javadoc tags most accurately documents the method's contract?
Answer: `@param value the value to limit
@param min the lower bound
@param max the upper bound
@return the value limited to the inclusive range
@throws IllegalArgumentException if min is greater than max`
When writing Javadoc, your goal is to precisely document what each parameter means, what the method actually returns, and exactly when each exception is thrown. Compare every tag against the real code behavior — don't just check if it sounds plausible.
Looking at the code, value is what gets clamped, min is the lower bound, and max is the upper bound. The return statement Math.max(min, Math.min(value, max)) produces a result within the inclusive range [min, max] — not necessarily the original value, not strictly between bounds. The exception fires when min > max, and only then.
Option A matches perfectly: parameters are described correctly, the return describes "the value limited to the inclusive range," and the exception condition is precisely min > greater than max. This is your correct answer.
Option B swaps the descriptions of value and min, claiming value is the lower bound and min is the value to clamp — a clear mislabeling. It also states the exception fires when value is outside the range, which never happens in this code.
Option C falsely documents the return as "the original value in every case," which contradicts the entire purpose of clamping. It also says the exception fires when min equals max, but the code only throws when min > max — equal bounds are actually valid.
Option D uses @param minimum and @param maximum instead of min and max, which don't match the actual parameter names. It also reverses the exception condition (max exceeds min instead of min exceeds max) and incorrectly calls the return "strictly between both bounds," excluding the boundary values themselves.
A good study habit: always verify Javadoc against the exact variable names, actual return logic, and literal exception condition in the source — every word matters.
- Which placement correctly associates the Javadoc comment with the method?
Answer: `/** Restores the counter to zero. */
@Override
public void reset() { count = 0; }`
When working with Javadoc in Java, placement is everything. A Javadoc comment (/** ... */) documents whatever immediately follows it — no annotations, blank lines, or other statements in between. Annotations like @Override are considered part of the method declaration, so a Javadoc comment placed directly before the annotation still correctly associates with the method that follows.
Option A is correct because the /** ... */ comment appears immediately before @Override public void reset(). Java's Javadoc tool reads the comment, skips any annotations, and attaches the documentation to the method declaration. This is the standard, accepted pattern you'll see throughout professional Java code.
Option B uses /* ... */ — a regular block comment, not a Javadoc comment. The double asterisk (/**) is what triggers Javadoc processing; a single asterisk produces a comment that javadoc completely ignores. Additionally, inserting any comment between @Override and the method signature is poor practice and won't generate docs.
Option C places the /** ... */ comment inside the method body. Javadoc only processes comments that appear before declarations (classes, fields, constructors, methods). A Javadoc comment buried inside a method body is ignored by the javadoc tool entirely.
Option D uses a single-line comment (//), which is never processed by Javadoc under any circumstances. Single-line comments are strictly for inline developer notes and produce no generated documentation.
A quick tip to remember: valid Javadoc always starts with /**, sits outside and immediately before the element it documents, and may have annotations between it and the method signature — that's completely fine.
