Java 21 1Z0-830: Logging and Annotations

Topic snapshot

Sample questions

These questions are original IT Mastery practice items aligned to this topic area. They are designed for self-assessment and are not official exam questions.

Question 1

Topic: Logging API and Standard Annotations

A developer adds @SafeVarargs to silence warnings on a helper method. In Java 21, compilation fails with: Invalid SafeVarargs annotation. Instance method printAll(List<String>...) is neither final nor private.

class Reporter {
    @SafeVarargs
    void printAll(List<String>... groups) {
        for (List<String> g : groups)
            System.out.println(g.size());
    }
}

Which change is the best fix while keeping the varargs API and using the annotation appropriately?

Options:

• A. Declare Reporter as abstract.

• B. Change the parameter to List<String>[] groups.

• C. Replace @SafeVarargs with @FunctionalInterface.

• D. Declare printAll as final.

Best answer: D

Explanation: @SafeVarargs can be used only on constructors and on varargs methods that cannot be overridden: final, static, or private methods. Here, List<String>... is a non-reifiable varargs parameter, so heap-pollution warnings are relevant, but the instance method must first be made eligible for the annotation.

@SafeVarargs is a programmer assertion that a varargs method does not perform unsafe operations with its varargs array. Java restricts the annotation to declarations where overriding cannot introduce an unsafe implementation: constructors, static methods, final methods, and private methods. The shown method is an ordinary instance method, so the compiler rejects the annotation even though List<String>... is exactly the kind of non-reifiable varargs parameter where heap-pollution warnings can occur.

Making the method final keeps the varargs API and makes the annotation legal, assuming the method body remains safe.

• Abstract class does not prevent overriding of the method and does not satisfy the @SafeVarargs rule.
• FunctionalInterface applies to interface declarations, not to suppressing varargs heap-pollution warnings.
• Array parameter removes the varargs declaration, so @SafeVarargs would no longer apply.

Question 2

Topic: Logging API and Standard Annotations

In a Java SE 21 import tool, a catch block receives a caught Exception ex and a record ID id. The team wants to create a diagnostic event with a severity level and the throwable attached for configured logging handlers; the choice to continue or abort should remain separate. Assume logger is a java.util.logging.Logger. Which line best fits that requirement?

Options:

• A. System.out.println("WARNING: Bad record " + id + ex);

• B. logger.log(Level.WARNING, "Bad record " + id, ex);

• C. ex.printStackTrace(System.out);

• D. throw new RuntimeException("Bad record " + id, ex);

Best answer: B

Explanation: The Java Logging API records events for configured handlers and can include a severity level plus a Throwable. It is separate from exception handling, which changes control flow, and from standard output printing, which just writes text to a stream.

java.util.logging.Logger is used to publish log records, such as WARNING messages, to configured handlers. The overload log(Level, String, Throwable) records both the message and the exception details while leaving the program’s control-flow decision to surrounding code. Throwing a new exception is exception handling behavior, not logging. Writing to System.out or printing a stack trace to it bypasses logger levels, filters, formatters, and handlers.

The key distinction is that logging reports an event; it does not replace exception handling or console output.

• Throwing an exception changes control flow and may abort the current operation rather than merely recording a diagnostic event.
• Standard output text lacks logger levels, handlers, filters, and structured exception attachment.
• Stack trace printing can show exception details, but it writes directly to a stream instead of using the logging framework.

Question 3

Topic: Logging API and Standard Annotations

A Java SE 21 application uses java.util.logging. A log record must indicate an intended severity of a serious failure, rather than a warning, informational event, configuration message, or diagnostic trace. Which predefined Level constant is appropriate?

Options:

• A. Level.FINE

• B. Level.INFO

• C. Level.SEVERE

• D. Level.WARNING

Best answer: C

Explanation: java.util.logging.Level provides predefined severity levels. For a message whose intended severity is a serious failure, Level.SEVERE is the appropriate standard level. Lower levels such as WARNING, INFO, and FINE represent less severe conditions or diagnostic detail.

In java.util.logging, the predefined levels communicate the intended importance of a log record. SEVERE is used for serious failures. WARNING is for potential problems, INFO is for normal informational messages, and FINE is one of the lower diagnostic or tracing levels. The stem explicitly describes a serious failure, so the level should match that severity rather than merely reporting a warning or routine event.

The key takeaway is to choose the level based on the meaning of the event, not just whether the application continues running.

• Warning confusion fails because WARNING is for potential problems, not the stated serious failure.
• Informational event fails because INFO describes routine messages, not failures.
• Trace detail fails because FINE is intended for diagnostic detail below normal informational logging.

Question 4

Topic: Logging API and Standard Annotations

Given this Java 21 code, what is printed?

import java.util.logging.*;

public class LogCheck {
    public static void main(String[] args) {
        Logger first = Logger.getLogger("demo.audit");
        Logger second = Logger.getLogger("demo.audit");
        first.setLevel(Level.WARNING);
        System.out.print((first == second) + " ");
        System.out.print(second.isLoggable(Level.INFO) + " ");
        second.setLevel(Level.FINE);
        System.out.print(first.isLoggable(Level.INFO));
    }
}

Options:

• A. It prints false false true.

• B. It prints true false false.

• C. It prints true true true.

• D. It prints true false true.

Best answer: D

Explanation: Logger.getLogger(String) returns the named logger managed by the logging system, so both variables refer to the same logger. The logger level is a threshold: INFO is not loggable at WARNING, but it is loggable after the level is changed to FINE.

The key Java Logging API behavior is that named loggers are obtained from the logging system by name. In this code, first and second refer to the same named Logger, so first == second is true. A logger’s level acts as a minimum severity threshold for isLoggable. Level.WARNING is higher than Level.INFO, so an INFO record is not loggable when the logger is set to WARNING. After second.setLevel(Level.FINE), the same logger object now has a lower threshold, and INFO is loggable. Handler configuration and console formatting are not involved because the code calls isLoggable and prints booleans directly.

• Separate-instance assumption fails because repeated lookup of the same logger name returns the same live named logger.
• Reversed level ordering fails because INFO is below WARNING but above FINE.
• Handler confusion fails because isLoggable checks the logger’s effective level, not console handler output.

Question 5

Topic: Logging API and Standard Annotations

A developer is writing a Java SE 21 practice question about this code. No logging.properties, system property, handler list, logger level, or filter setting is supplied in the question.

import java.util.logging.Logger;

class Job {
    private static final Logger LOG =
        Logger.getLogger(Job.class.getName());

    static void run() {
        LOG.info("begin");
        LOG.warning("retry");
    }
}

Which conclusion correctly applies only Java SE logging behavior under these stated facts?

Options:

• A. Neither message can be logged unless a handler is created in code.

• B. Only the WARNING message must be printed by default.

• C. Both messages must be printed by the default console handler.

• D. It makes INFO and WARNING requests; output is configuration-dependent.

Best answer: D

Explanation: The code uses java.util.logging.Logger and calls convenience methods for INFO and WARNING. Java SE defines logging levels and the logger/handler model, but it does not let this snippet alone prove what appears on the console. Output depends on configuration not supplied in the stem.

Java Util Logging separates a logging request from publication. A Logger may check its effective level and filters, then pass accepted records to handlers; handlers also have levels, filters, formatters, and destinations. Those details can be supplied by LogManager configuration or by code. Since the question gives only the logger calls and no configuration, the stable conclusion is limited to the Java SE API behavior shown: the program makes INFO and WARNING logging requests. A deterministic output question would need to provide the relevant logger and handler configuration explicitly.

• Default console assumption fails because the stem does not provide the active handlers, their levels, or their destination.
• WARNING-only assumption fails because it relies on an unstated default threshold rather than facts in the question.
• Mandatory in-code handler fails because JUL can use configured handlers; they do not have to be created in the shown method.

Question 6

Topic: Logging API and Standard Annotations

Which use of a named standard annotation is valid in Java 21?

Options:

• A. Use @Deprecated on a local variable declaration.

• B. Use @SafeVarargs on a non-final public instance varargs method.

• C. Use @FunctionalInterface on a concrete class with one public method.

• D. Use @Override on a method implementing an interface method.

Best answer: D

Explanation: Java 21 allows @Override on a method that implements an interface method. The annotation is checked by the compiler to ensure the annotated method really overrides or implements an inherited method declaration.

The named standard annotations have specific valid use sites and, for some, extra compiler rules. @Override is targeted at methods and is valid when the method overrides a superclass method or implements an interface method. @FunctionalInterface is for interface type declarations, not concrete classes. @SafeVarargs is restricted to constructors and certain varargs methods, such as static, final, or private methods; a non-final public instance method is not allowed. @Deprecated can annotate declarations such as classes, methods, fields, constructors, packages, and modules, but not local variables. The key is to match both the annotation target and any special Java compiler rule.

• Concrete class target fails because @FunctionalInterface is intended for interface declarations.
• Unsafe varargs target fails because a non-final public instance varargs method can be overridden.
• Local deprecation fails because @Deprecated is not valid on local variable declarations.

Question 7

Topic: Logging API and Standard Annotations

A developer silenced a compiler warning in this Java 21 code. The code compiles, but running it throws a ClassCastException at the line marked // here. What is the best cause or next fix?

import java.util.*;

class Audit {
    @SuppressWarnings("unchecked")
    static List<Integer> read() {
        List raw = List.of("7");
        return (List<Integer>) raw;
    }
    public static void main(String[] args) {
        int value = read().get(0); // here
        System.out.println(value + 1);
    }
}

Options:

• A. Add @Override to read().

• B. Add @Deprecated to read().

• C. Make the list actually contain Integer values.

• D. Replace it with @SafeVarargs.

Best answer: C

Explanation: The failure is caused by relying on @SuppressWarnings for something it does not do. It can suppress unchecked compiler warnings, but it does not validate generic element types or prevent a runtime ClassCastException.

Standard annotations such as @SuppressWarnings, @Deprecated, @Override, @FunctionalInterface, and @SafeVarargs are mainly compile-time or documentation signals. Here, the unchecked cast to List<Integer> is allowed after the warning is suppressed, but type erasure means the list’s element type is not verified at that cast. When read().get(0) is used as an Integer, the runtime value is still a String, so the inserted cast fails. The fix is to return data whose actual elements match the declared generic type, such as List.of(7), or change the declared type.

• SafeVarargs misuse fails because @SafeVarargs applies to eligible varargs methods or constructors and does not inspect list elements.
• Deprecation warning fails because @Deprecated warns callers at compile time or in documentation, not at runtime.
• Override checking fails because @Override only checks method overriding at compile time and cannot affect casts.

Question 8

Topic: Logging API and Standard Annotations

A team uses @FunctionalInterface so the compiler rejects interfaces that cannot be lambda targets. Given these Java 21 declarations, which one is valid?

@FunctionalInterface interface A { void go(); boolean equals(Object o); }
@FunctionalInterface interface B { void go(); Object clone(); }
@FunctionalInterface interface C { default void go() {} }
@FunctionalInterface interface D { void go(); void stop(); }

Options:

• A. interface A

• B. interface B

• C. interface C

• D. interface D

Best answer: A

Explanation: @FunctionalInterface requires the annotated interface to have exactly one abstract method. Methods matching public methods of Object, such as equals(Object), do not count toward that total. Therefore interface A is the only valid declaration shown.

The compiler uses @FunctionalInterface as a validation check: the interface must have exactly one abstract method that can be implemented by a lambda. Abstract methods that are override-equivalent to public Object methods, such as equals, hashCode, or toString, are not counted. In the shown declarations, go() is the single counted abstract method in interface A, while equals(Object) is ignored for this purpose. The closest trap is clone(): Object.clone() is protected, not public, so Object clone() in an interface counts as another abstract method.

• Protected clone trap fails because clone() is not a public Object method and counts as a second abstract method.
• Default-only trap fails because a functional interface must have one abstract method, not zero.
• Two-operation trap fails because go() and stop() are both counted abstract methods.

Question 9

Topic: Logging API and Standard Annotations

A team is troubleshooting false outage alerts from this java.util.logging output. The cache warm-up failure should be visible because it may affect performance, but the application continues by loading cache entries on demand.

private static final Logger LOG = Logger.getLogger(Warmer.class.getName());

void warm() {
    try {
        cache.loadAll();
    } catch (IOException e) {
        LOG.log(Level.SEVERE, "Cache warm-up failed; using lazy loading", e);
    }
}

Which next fix best matches the intended severity?

Options:

• A. Change the record to Level.INFO.

• B. Use Level.CONFIG because caching is configuration-related.

• C. Log the event at Level.WARNING.

• D. Keep Level.SEVERE for any caught exception.

Best answer: C

Explanation: The event is a runtime problem, but the application continues with a fallback. In java.util.logging, WARNING fits potentially harmful or notable recoverable conditions, while SEVERE is for serious failures.

java.util.logging.Level values communicate severity as well as control filtering. A cache warm-up IOException that triggers lazy loading is not normal progress, so it should not be treated as a routine INFO message. But it also does not stop the application or represent an outage, so SEVERE overstates the condition and can cause false alerts. WARNING is the best level for a recoverable condition that operators should notice.

The key takeaway is to choose the level from the intended operational severity, not merely from the presence of an exception.

• Any exception is severe fails because caught, recoverable exceptions can be logged below SEVERE.
• Routine information fails because the failed warm-up is a problem, not normal lifecycle output.
• Configuration level fails because CONFIG is for configuration messages, not runtime I/O failures.

Question 10

Topic: Logging API and Standard Annotations

A method contains one unavoidable unchecked cast introduced by a legacy API call. The rest of the class should still report unrelated warnings during compilation. Which use of @SuppressWarnings follows the Java 21 rule and proper scope?

Options:

• A. Use @SuppressWarnings("deprecation") on the method.

• B. Use @SuppressWarnings({"unchecked", "deprecation"}) on the class.

• C. Use @SuppressWarnings("unchecked") directly on the cast expression.

• D. Use @SuppressWarnings("unchecked") on the smallest applicable enclosing declaration.

Best answer: D

Explanation: @SuppressWarnings suppresses named compiler warnings only within the scope of the annotated element. For one unchecked cast, the relevant warning name is unchecked, and the annotation should be placed on the narrowest applicable declaration that encloses that warning.

@SuppressWarnings is a source-level annotation used to tell the compiler to suppress specific warning categories for an annotated program element. The suppression applies within that element’s scope, so broad placement can hide unrelated warnings. For an unavoidable unchecked cast, use the unchecked warning name and place the annotation on the smallest valid enclosing declaration, such as a local variable declaration or method when needed. It does not prevent runtime exceptions, and it is not applied to arbitrary cast expressions. The key is to suppress only the relevant compiler warning in only the code that needs it.

• Class-wide suppression is too broad and also includes deprecation, which is unrelated to the unchecked cast.
• Cast-expression placement fails because @SuppressWarnings is not applied directly to arbitrary expressions.
• Deprecation suppression targets a different warning category and does not match an unchecked cast warning.

Continue with full practice

Use the Java 21 1Z0-830 Practice Test page for the full IT Mastery route, mixed-topic practice, timed mock exams, explanations, and web/mobile app access.

Try Java 21 1Z0-830 on Web View Java 21 1Z0-830 Practice Test

Related focused pages

• Free Java 21 1Z0-830 Full-Length Practice Exam
• Core Value Types
• Controlling Program Flow
• Object-Oriented Java
• Handling Exceptions
• Working with Arrays and Collections
• Streams and Lambdas
• Packaging and Deploying Java Code
• Managing Concurrent Code Execution
• Using Java I/O API
• Implementing Localization

Free review resource

Read the Java 21 1Z0-830 Cheat Sheet on Tech Exam Lexicon, then return to IT Mastery for timed practice.