- Which refactoring follows Java conventions for the record type and component and uses the generated accessor correctly?
Answer: record ShippingLabel(String trackingNumber) { } with label.trackingNumber()
When working with Java records, you need to apply two separate naming conventions simultaneously: one for the record type itself, and one for its components (fields). Java conventions require that type names use PascalCase (also called UpperCamelCase), while component names use camelCase (lowercase first letter). Records also generate accessor methods automatically — and critically, those accessors are named after the component directly, not prefixed with get like traditional JavaBeans.
Option B gets everything right: ShippingLabel follows PascalCase for the record type, trackingNumber follows camelCase for the component, and label.trackingNumber() correctly uses the auto-generated accessor, which mirrors the component name exactly.
Option A uses shippingLabel for the record name — that's camelCase, which is correct for variables and methods, but type names must start with an uppercase letter. The accessor label.trackingNumber() is correct, but the naming violation disqualifies this choice.
Option C keeps the component name as TrackingNumber with an uppercase T — that violates camelCase for components. Additionally, label.getTrackingNumber() is wrong because Java records **do not generate get-prefixed accessors**. That's a JavaBeans pattern, not a records pattern.
Option D uses tracking_number with an underscore, which violates Java's camelCase convention for identifiers entirely. The accessor label.tracking_number() would match that broken component name, but the naming style itself is non-idiomatic Java.
A helpful tip: whenever you see a Java records question, mentally check two things — does the type start uppercase (PascalCase)? Does the component start lowercase (camelCase)? And remember, accessors in records match the component name with no get prefix.
- Which set of names conventionally distinguishes the interface type, callback method, and field while preserving the override?
Answer: PaymentListener, paymentCompleted, and paymentListener
When reading Java code, one of the first things you should check is whether naming conventions match the language's standard style guidelines. Java uses PascalCase for interfaces and classes, camelCase for methods and fields, and discourages underscores in most identifiers (outside constants).
Here's how those rules apply to this passage. The interface payment_listener should become PaymentListener — PascalCase, no underscores. The callback method PaymentCompleted starts with a capital letter, which violates Java's method convention; it should be paymentCompleted (camelCase, lowercase first letter). The field Listener is capitalized like a class, which is wrong for a field; it should be paymentListener — descriptive, camelCase, lowercase first letter. Critically, renaming both the method declaration in the interface and the override in CheckoutScreen to paymentCompleted preserves the override relationship, since Java matches overrides by exact method signature.
That makes D correct: PaymentListener, paymentCompleted, and paymentListener follow all three conventions while keeping the override intact.
A fails immediately because paymentListener uses camelCase for the interface name — interfaces must be PascalCase. B gets the interface right (PaymentListener) but uses PaymentCompleted for the method, which capitalizes the first letter incorrectly for a method name, violating camelCase. C uses payment_completed with an underscore for the method name, which is a Python or C-style convention, not Java.
A quick memory trick: in Java, classes and interfaces get capital starts, everything else gets lowercase starts — methods, variables, and fields all begin with a lowercase letter in camelCase.
- Which refactoring correctly names the enum type, method, and local variable?
Answer: DeliveryStatus, currentStatus, and deliveryStatus
When writing Java code, naming conventions aren't just style preferences — they're standardized rules that every professional Java developer follows, and exam questions frequently test whether you know them. The three conventions at play here are: PascalCase for class and enum type names, camelCase for methods and local variables, and SCREAMING_SNAKE_CASE for enum constants (which the question tells you to leave alone).
Applying those rules: the enum type delivery_status should become DeliveryStatus (PascalCase), the method current_status() should become currentStatus() (camelCase), and the local variable delivery_status should become deliveryStatus (camelCase). That's exactly what B gives you — making it the correct answer.
A is wrong because it renames the enum type to deliveryStatus using camelCase, which is reserved for methods and variables, not type declarations. Enum types are class-like constructs and must use PascalCase.
C incorrectly capitalizes the method name as CurrentStatus, applying PascalCase where camelCase is required. Methods always start with a lowercase letter in Java — PascalCase is strictly for types (classes, interfaces, enums).
D makes two errors: it leaves the method name as current_status in snake_case (which Java convention never uses for methods or variables), and it renames the local variable to DeliveryStatus using PascalCase, which belongs only to type names.
A handy rule of thumb: types = PascalCase, methods/variables = camelCase, constants = UPPER_SNAKE_CASE. If you memorize just that triangle, you can eliminate wrong answers quickly on any naming-convention question.
- Which revised names satisfy the package, class, and method conventions?
Answer: com.acme.orderprocessing, OrderService, and submitOrder
When you see a question about Java naming conventions, mentally run through three separate checklists: packages (all lowercase), classes (PascalCase), and methods (camelCase starting with a lowercase letter).
The original code violates all three conventions. The package com.Acme.orderProcessing has uppercase letters, the class order_service uses snake_case instead of PascalCase, and the method Submit_Order starts with an uppercase letter and uses an underscore. A fully corrected version needs: a package where every component is entirely lowercase, a class name where each word starts with a capital letter (no underscores), and a method name that starts lowercase with subsequent words capitalized.
Answer A — com.acme.orderprocessing, OrderService, submitOrder — satisfies all three rules. The package is fully lowercase, the class uses PascalCase, and the method uses camelCase. This is your correct answer.
Answer B fails because orderProcessing retains a capital "P" inside the package name. The problem explicitly states that all package components must be entirely lowercase, and orderProcessing violates that.
Answer C fails on the class name. orderService starts with a lowercase letter, which is the convention for methods and variables, not classes. Classes require PascalCase, so it should be OrderService.
Answer D fails on the method name. SubmitOrder starts with an uppercase letter, making it look like a constructor or class name rather than a method. Correct method convention requires the first letter to be lowercase: submitOrder.
A handy memory trick: Packages go flat (all lowercase), Classes get Capitals (PascalCase), and methods start modestly (camelCase).
- Which subclass declaration satisfies both requirements?
Answer: class FileSource extends DataSource { @Override void loadData() { } }
When a question asks about method overriding and naming conventions together, you need to verify two independent conditions: does the method signature exactly match the parent class, and does the code follow Java's standard style guidelines?
For a valid override in Java, the subclass method must have the exact same name, return type, and parameter list as the parent method. Java is case-sensitive, so loadData() and LoadData() are completely different methods. Additionally, Java naming conventions require classes to use PascalCase (e.g., FileSource) and methods to use camelCase (e.g., loadData). The @Override annotation is a best practice that tells the compiler to verify you're actually overriding a parent method — if the signature doesn't match, the compiler throws an error, protecting you from silent mistakes.
Option D satisfies everything: FileSource is properly capitalized, loadData() exactly matches the parent signature, and @Override documents intent while enabling compile-time checking. This is your correct answer.
Option A fails because LoadData() starts with a capital letter — this doesn't match loadData() and is simply a new method, not an override. Option B uses fileSource as the class name, which violates PascalCase naming conventions for classes, even though the method itself is correct. Option C correctly names the class but defines load_data(), which uses underscore-style naming (not camelCase) and doesn't match the parent method — another failed override.
Study tip: On Java questions, always check two things separately — signature match (for override validity) and capitalization/style (for naming conventions). Failing either one is enough to disqualify an answer.
- Which set of renamed declarations follows standard Java naming conventions for every identifier shown?
Answer: InvoiceProcessor, calculateTotal, unitPrice, and itemCount
Java naming conventions are one of those foundational topics where the rules are precise, so let's break them down clearly. When you see a question like this, mentally sort identifiers into three buckets: classes, methods, and variables — each follows a distinct casing rule.
Classes use PascalCase (every word capitalized, no underscores): InvoiceProcessor. Methods and variables both use camelCase (first word lowercase, subsequent words capitalized): calculateTotal, unitPrice, itemCount. The original code violates these conventions with snake_case class/method names and an all-lowercase class name, so every identifier needs updating.
Choice C is correct because it applies each rule precisely: InvoiceProcessor is proper PascalCase for the class, calculateTotal is proper camelCase for the method, and unitPrice/itemCount are proper camelCase for the parameters.
Choice A fails because CalculateTotal uses PascalCase for a method — that's reserved for classes and constructors, not methods. This is a very common trap, since capitalizing a method name looks "formal" but breaks convention. Choice B fails because invoiceProcessor uses camelCase for the class name — classes must start with an uppercase letter. Choice D fails on both parameters: UnitPrice and ItemCount apply PascalCase to variable names, which is incorrect and would actually suggest these are classes, not variables.
A quick memory device: Classes are Capitalized, everything else starts lowercase (in camelCase). On Java exams, watch for distractors that mix up which identifiers get PascalCase versus camelCase — that's the most common trick in naming convention questions.
- Which complete refactoring meets both goals?
Answer: Rename the file to CustomerAccount.java, the class to CustomerAccount, and the method to getBalance.
When you see a question about Java naming conventions and compilation rules, you need to juggle two independent requirements simultaneously: Java's style conventions and its compiler enforcement rules.
Java's compiler enforces one hard rule: a public class must live in a source file whose name exactly matches the class name, including case, with a .java extension. Separately, Java's widely accepted style conventions dictate that class names use UpperCamelCase (e.g., CustomerAccount) and method names use lowerCamelCase (e.g., getBalance). Underscores in class or method names are not conventional Java style.
Option C is correct because it satisfies both requirements cleanly: renaming the file to CustomerAccount.java matches the public class name CustomerAccount (satisfying the compiler), CustomerAccount follows UpperCamelCase (satisfying style), and getBalance follows lowerCamelCase (satisfying style).
Option A fails because customerAccount starts with a lowercase letter — that violates the UpperCamelCase convention for class names, even though the file and class names do match each other.
Option B gets the class name and filename right, but GetBalance starts with an uppercase letter, which violates lowerCamelCase for method names. Methods should never be capitalized like classes.
Option D keeps the filename as customer_account.java while renaming the class to CustomerAccount — this breaks the compiler rule entirely, since a public class named CustomerAccount must reside in CustomerAccount.java. The code would not compile.
A handy memory rule: classes dress formally (Capital start), methods dress casually (lowercase start), and the filename always mirrors the public class exactly.
- After the class is renamed, which pair of declarations is both valid Java and conventionally named?
Answer: public ReportGenerator() { } and public void generateReport() { }
When you see a question about Java naming, you should immediately think about two separate conventions: PascalCase for class names and constructors, and camelCase for methods.
In Java, a constructor must share the exact same name as its class — this is a language rule, not just style. So if the class is renamed ReportGenerator (PascalCase, which is the Java convention for class names), the constructor must also be declared as public ReportGenerator() { }. Java method names, on the other hand, should follow camelCase, meaning the first word is lowercase and subsequent words are capitalized — so generateReport() is the conventional form.
Option A gives you public ReportGenerator() { } paired with public void generateReport() { }. The constructor matches a properly named class, and the method follows camelCase — this is both valid and conventional, making it the correct answer.
Option B uses reportGenerator for the constructor, which implies the class name starts lowercase. That violates Java's class-naming convention, and a constructor starting with a lowercase letter would be misleading and unconventional.
Option C pairs a correct constructor name with GenerateReport() for the method. The method here uses PascalCase, which is reserved for class names — methods should use camelCase, so GenerateReport() is unconventional even though it's technically valid.
Option D keeps the original snake_case name report_generator, which is exactly what the developer is trying to move away from — it's neither conventional nor renamed.
A useful rule of thumb: classes and constructors = PascalCase, methods and variables = camelCase. Memorize this pair and you'll handle Java naming convention questions quickly and confidently.
- Which revised annotation declaration and use follow standard Java naming conventions?
Answer: @interface RetryPolicy { int maxAttempts(); } used as @RetryPolicy(maxAttempts = 3)
When working with Java naming conventions, you need to remember three distinct rules that apply to different identifiers: annotation types follow PascalCase (like class names), while annotation elements (methods) follow camelCase (like regular methods). Underscores and all-lowercase names are generally reserved for constants and packages respectively, not for types or methods.
The original code violates conventions on both counts — retry_policy uses snake_case for the annotation type, and MaxAttempts uses PascalCase for what should be a camelCase element method. The corrected version in C fixes both issues properly: @interface RetryPolicy applies PascalCase to the annotation type name, and int maxAttempts() applies camelCase to the element. Its usage @RetryPolicy(maxAttempts = 3) mirrors these corrections consistently.
A is wrong because retryPolicy uses camelCase for the annotation type name — annotation types should be PascalCase, just like classes. The element maxAttempts is actually correct, but the type name disqualifies this option.
B is wrong because MaxAttempts keeps the original mistake — annotation element methods should follow camelCase, so it should be maxAttempts, not MaxAttempts. The type name RetryPolicy is fine, but the element is wrong.
D is wrong because it introduces snake_case (Retry_policy, max_attempts), which isn't standard for either annotation types or element methods in Java. This pattern belongs to constants (MAX_VALUE), not to type or method names.
A handy rule of thumb: in Java, types are PascalCase, methods and variables are camelCase, constants are SCREAMING_SNAKE_CASE. Annotations follow the same rules as classes and methods, so apply this pattern consistently.
- Which refactoring applies the appropriate convention to the type, mutable field, and method?
Answer: SessionRegistry, activeSessionCount, and resetCount
Java has strict naming conventions that every developer is expected to follow, and this question tests whether you can apply all three at once: class names, field names, and method names.
In Java, class names use PascalCase (also called UpperCamelCase), meaning every word starts with a capital letter — so session_registry becomes SessionRegistry. Non-constant instance and static fields use lowerCamelCase, meaning the first word is lowercase and subsequent words are capitalized — so active_session_count becomes activeSessionCount. The question explicitly reminds you this field is mutable, which matters because only static final constants use ALL_CAPS_WITH_UNDERSCORES. Finally, method names also use lowerCamelCase, so ResetCount becomes resetCount.
That logic points directly to B: SessionRegistry, activeSessionCount, and resetCount — all three conventions correctly applied.
A is wrong because ACTIVE_SESSION_COUNT uses the constant naming style (ALL_CAPS), but the question clearly states this field is not a constant. Using ALL_CAPS for a mutable field is a misleading convention violation.
C is wrong because sessionRegistry uses lowerCamelCase for the class name, when classes require PascalCase. It also keeps ResetCount capitalized, which violates method naming conventions.
D is wrong because ActiveSessionCount treats the field like a class name (PascalCase). Fields should never use PascalCase in Java — that style is reserved for class and interface names.
A useful tip: whenever you see ALL_CAPS, that's exclusively for static final constants in Java. If a field can change, it must use lowerCamelCase, no exceptions.
