Try 10 focused Java 21 1Z0-830 questions on Core Value Types, with explanations, then continue with IT Mastery.
Open the matching IT Mastery practice page for timed mocks, topic drills, progress tracking, explanations, and full practice.
Try Java 21 1Z0-830 on Web View full Java 21 1Z0-830 practice page
| Field | Detail |
|---|---|
| Exam route | Java 21 1Z0-830 |
| Topic area | Handling Date, Time, Text, Numeric, and Boolean Values |
| Blueprint weight | 10% |
| Page purpose | Focused sample questions before returning to mixed practice |
Use this page to isolate Handling Date, Time, Text, Numeric, and Boolean Values for Java 21 1Z0-830. Work through the 10 questions first, then review the explanations and return to mixed practice in IT Mastery.
| Pass | What to do | What to record |
|---|---|---|
| First attempt | Answer without checking the explanation first. | The fact, rule, calculation, or judgment point that controlled your answer. |
| Review | Read the explanation even when you were correct. | Why the best answer is stronger than the closest distractor. |
| Repair | Repeat only missed or uncertain items after a short break. | The pattern behind misses, not the answer letter. |
| Transfer | Return to mixed practice once the topic feels stable. | Whether the same skill holds up when the topic is no longer obvious. |
Blueprint context: 10% of the practice outline. A focused topic score can overstate readiness if you recognize the pattern too quickly, so use it as repair work before timed mixed sets.
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.
Topic: Handling Date, Time, Text, Numeric, and Boolean Values
A reporting service must move a February 2025 start date to the last day of that month, subtract one week, and then count whole days from the original start date to that cutoff. The current code prints the original date and 0 days.
var start = LocalDate.of(2025, 2, 10);
var cutoff = start;
cutoff.withDayOfMonth(cutoff.lengthOfMonth());
cutoff.minusWeeks(1);
long days = ChronoUnit.DAYS.between(start, cutoff);
System.out.println(cutoff + " " + days);
Which refactoring is the best fix?
Options:
A. Keep the existing cutoff assignments, but replace between(start, cutoff) with start.until(cutoff, ChronoUnit.DAYS).
B. Assign start.withDayOfMonth(start.lengthOfMonth()).minusWeeks(1) to cutoff, then use start.until(cutoff, ChronoUnit.DAYS).
C. Assign the chained result to cutoff, then use cutoff.until(start, ChronoUnit.DAYS).
D. Assign only start.withDayOfMonth(start.lengthOfMonth()) to cutoff, then call cutoff.minusWeeks(1) before counting.
Best answer: B
Explanation: LocalDate is immutable, so withDayOfMonth() and minusWeeks() do not modify the existing object. The fixed code must store the chained result and count days in the correct direction from start to cutoff.
Date-time objects such as LocalDate are immutable. Methods like plus, minus, and with return a new value; ignoring the returned value leaves the original reference unchanged. For February 10, 2025, the last day of the month is February 28, and subtracting one week gives February 21. Counting from February 10 until February 21 with start.until(cutoff, ChronoUnit.DAYS) gives 11. ChronoUnit.DAYS.between(start, cutoff) would also work after cutoff is assigned correctly, but the key fix is preserving the returned date-time value and using the correct direction.
between to until does not make withDayOfMonth() or minusWeeks() mutate cutoff.minusWeeks(1) without assigning its return value leaves cutoff at February 28.cutoff.until(start, DAYS) counts backward and produces a negative value.Topic: Handling Date, Time, Text, Numeric, and Boolean Values
A payment import test in Java 21 requires rounding to the nearest whole unit, with half values rounded away from zero. All inputs are finite and fit in a long. The test expected 3 -3, but this program prints 3 -2:
class RoundingCheck {
static long toUnits(double amount) {
return Math.round(amount);
}
public static void main(String[] args) {
System.out.println(toUnits(2.5) + " " + toUnits(-2.5));
}
}
Which change best matches the stated rounding policy?
Options:
A. return amount < 0 ? -Math.round(-amount) : Math.round(amount);
B. return (long) Math.ceil(amount);
C. return (long) amount;
D. return Math.round((float) amount);
Best answer: A
Explanation: Math.round(double) does not implement half-away-from-zero for negative half values. It returns a long based on floor(x + 0.5), which makes -2.5 become -2. Handling negative values separately matches the required policy.
The key Math API rule is that Math.round(double) returns a long and is specified as rounding as if by floor(argument + 0.5) for ordinary finite values. For 2.5, this produces floor(3.0), or 3. For -2.5, it produces floor(-2.0), or -2, not -3. If the business rule is nearest whole unit with half values away from zero, the code must make that policy explicit, such as rounding the positive magnitude and restoring the sign. Changing casts or using ceil changes the operation rather than fixing the stated rounding rule.
(long) amount discards the fractional part toward zero, so it is not nearest rounding.Math.ceil rounds toward positive infinity, which still gives -2 for -2.5.Math.round(float) returns int and keeps the same negative-half behavior for this test.Topic: Handling Date, Time, Text, Numeric, and Boolean Values
A team is troubleshooting a normalization method. The code compiles, but the test expected [AB21] and the program prints [ ab-21 ]. What is the best next fix?
public class TicketCleaner {
static void clean(String id) {
id.strip();
id.toUpperCase();
id.replace("-", "");
}
public static void main(String[] args) {
String id = " ab-21 ";
clean(id);
System.out.println("[" + id + "]");
}
}
Options:
A. Change clean to return the chained String and assign it.
B. Call id.intern() inside clean before the other calls.
C. Declare id in main as final before calling clean.
D. Replace strip() with trim() because trim() mutates the string.
Best answer: A
Explanation: String is immutable, so methods such as strip(), toUpperCase(), and replace() do not change the existing object. They return new String values. Because the code ignores those return values and clean returns nothing, main still prints the original text.
The core issue is String immutability. Each transformation creates a new String; it does not modify the object referenced by id. Also, the parameter id in clean is a local variable, so the caller will not see a different reference unless the method returns it and main assigns it.
A suitable fix is to make clean return the normalized value, for example return id.strip().toUpperCase().replace("-", "");, and call it as id = clean(id);. Changing final, interning, or swapping strip() for trim() does not make String mutable.
main; it does not apply transformations.trim() also returns a new String.Topic: Handling Date, Time, Text, Numeric, and Boolean Values
Which statement describes a Java 21 StringBuilder rule for chaining text updates?
Options:
A. delete(start, end) removes the character at end.
B. replace(start, end, s) requires s to have the same length.
C. reverse() creates a new builder and preserves the original.
D. These mutator methods update and return the same builder.
Best answer: D
Explanation: StringBuilder is mutable. Its common update methods change the same character sequence and return that same builder, so calls can be chained without creating a new builder for each step.
The core rule is that StringBuilder mutator methods operate on the receiver. Methods such as append(), insert(), delete(), replace(), and reverse() modify the builder’s current contents and return a StringBuilder reference to the same object. For range-based operations such as delete(start, end) and replace(start, end, str), the start index is inclusive and the end index is exclusive. The replacement text does not need to be the same length as the removed range. This is different from String, whose operations create new String objects because String is immutable.
reverse() mutates the existing builder rather than preserving it.delete(start, end) uses an exclusive end index.replace() can grow or shrink the builder.Topic: Handling Date, Time, Text, Numeric, and Boolean Values
In a protocol parser, a developer wants to initialize a byte status code at compile time without using an explicit cast. Which declaration compiles in Java SE 21?
Options:
A. byte code = 100 + 28;
B. byte code = 100 + 27L;
C. byte code = Integer.MAX_VALUE;
D. byte code = 100 + 27;
Best answer: D
Explanation: Integer literals such as 100 and 27 are int by default. Java allows an int constant expression to be assigned to byte without a cast only when the value is representable in the byte range, from -128 to 127.
The core rule is assignment conversion for constant expressions. Even though 100 + 27 has type int, it is a compile-time constant expression with value 127. Because 127 fits in a byte, Java permits the assignment without a cast. If the value is outside the byte range, or if the expression has type long because of an L suffix, this special narrowing rule does not apply.
The key takeaway is that default int literals can still initialize smaller primitive types only when the expression is a representable compile-time constant.
100 + 28 evaluates to 128, which is above the maximum byte value.100 + 27L has type long, not an eligible int constant expression for this narrowing rule.Integer.MAX_VALUE is far outside the byte range.Topic: Handling Date, Time, Text, Numeric, and Boolean Values
Assume all variables are int values and d is nonzero. Which fully parenthesized form matches Java 21’s precedence and associativity rules for the right-hand side?
int r = a - b * c / d + e;
Options:
A. (a - (b * (c / (d + e))))
B. (a - (((b * c) / d) + e))
C. ((a - ((b * c) / d)) + e)
D. (((a - b) * c) / (d + e))
Best answer: C
Explanation: Java applies explicit parentheses first, then operator precedence, then associativity for operators at the same level. Here, b * c / d groups before the additive operators, and both multiplicative and additive groups associate left to right.
The core rule is that multiplicative operators (*, /, %) have higher precedence than additive operators (+, -). Operators in each of those groups associate left to right. Therefore, b * c / d groups as ((b * c) / d), and a - ... + e groups as ((a - ...) + e). Parentheses would override these rules, but none are present in the original right-hand side.
a - b cannot group before b * c; multiplication has higher precedence.d + e does not happen before / without parentheses.a - x + e groups as (a - x) + e, not a - (x + e).Topic: Handling Date, Time, Text, Numeric, and Boolean Values
While troubleshooting a Java 21 service, you find this method. The requirement is that a missing rating should be treated as 0. The code compiles, but the call in main throws NullPointerException before printing anything. Which change best addresses the cause?
class Ratings {
static int clamp(Integer rating) {
if (rating < 0) {
return 0;
}
return rating;
}
public static void main(String[] args) {
System.out.println(clamp(null));
}
}
Options:
A. Cast the literal: rating < (Integer) 0.
B. Change the return type from int to Integer.
C. Add if (rating == null) return 0; before the comparison.
D. Replace < with rating.compareTo(0) < 0.
Best answer: C
Explanation: The failure is caused by unboxing a null Integer. Relational operators such as < operate on numeric primitives, so Java tries to convert rating to an int before doing the comparison. A null check before the comparison preserves the required behavior.
Wrapper types such as Integer can hold null, but numeric operators require primitive values. In rating < 0, Java unboxes rating to an int. Because the argument is null, that unboxing throws NullPointerException before the method can return anything. The same risk also exists when returning an Integer from a method declared to return int. Treating missing ratings as zero requires handling null before any numeric comparison or primitive assignment. The key takeaway is that autounboxing is convenient, but it does not provide a default value for null.
rating < 0 comparison from unboxing rating.rating, so a null argument would fail.< still requires numeric unboxing.Topic: Handling Date, Time, Text, Numeric, and Boolean Values
No imports are needed. What is the result of compiling and running this Java 21 code?
public class Report {
static void normalize(String s) {
s.strip();
s.concat("!");
}
public static void main(String[] args) {
String title = " log ";
normalize(title);
title.replace("o", "0");
System.out.print("[" + title + "]");
}
}
Options:
A. It prints [ log ].
B. It prints [log!].
C. It prints [ l0g ].
D. The code fails to compile.
Best answer: A
Explanation: String objects are immutable in Java. Methods such as strip(), concat(), and replace() do not modify the existing object; they return a new value that must be assigned or otherwise used.
The core concept is String immutability. The variable title refers to the original string containing two leading and two trailing spaces. Inside normalize, the parameter s receives a copy of that reference, but s.strip() and s.concat("!") return new String objects that are ignored. Back in main, title.replace("o", "0") also returns a new String, but that result is not assigned to title. Therefore, title still refers to the original string when it is printed. The key takeaway is that String methods can appear to describe a mutation, but they produce replacement values instead.
strip() nor concat() has its return value captured.replace() also returns a new String rather than changing title.Topic: Handling Date, Time, Text, Numeric, and Boolean Values
A developer calls s.strip() and then s.replace("a", "b") on a String reference, but does not assign either returned value. Which Java 21 rule determines the effect of those calls?
Options:
A. The existing characters are modified in place.
B. An UnsupportedOperationException is thrown.
C. The variable s is updated automatically.
D. The original String remains unchanged.
Best answer: D
Explanation: Java String objects are immutable. Methods that appear to transform text return a String result, and the caller must use that returned value to observe the change.
The core rule is String immutability: a String object’s character content cannot be changed after creation. Methods such as strip(), trim(), replace(), and substring() return a String value representing the requested result. If that result is ignored, the original reference still refers to the same unchanged text. Some methods may return the same object when no change is needed, but they still do not mutate the original object. To keep the changed text, assign or pass along the returned value.
StringBuilder, not String.String value is legal Java code.Topic: Handling Date, Time, Text, Numeric, and Boolean Values
A payroll method stores amounts in cents. The business rule is: first add baseCents and overtimeCents, then return 10% of that combined amount using integer arithmetic. Which replacement for the return statement best fixes the defect?
class Payroll {
static int bonusCents(int baseCents, int overtimeCents) {
return baseCents + overtimeCents * 10 / 100;
}
}
Options:
A. return (baseCents + overtimeCents * 10) / 100;
B. return baseCents + overtimeCents * (10 / 100);
C. return baseCents + overtimeCents * 10 / 100;
D. return (baseCents + overtimeCents) * 10 / 100;
Best answer: D
Explanation: Multiplication and division have higher precedence than addition in Java. To apply the percentage to the sum, the addition must be grouped explicitly with parentheses before the multiplication and division are evaluated.
Java evaluates * and / before +, with operators at the same precedence level evaluated left to right. The original expression computes baseCents + ((overtimeCents * 10) / 100), so only the overtime portion is reduced to 10%. Parentheses around baseCents + overtimeCents change the evaluation order so the combined amount is computed first, and then integer arithmetic applies the percentage. The closest trap is adding parentheses in a place that still leaves overtimeCents * 10 evaluated before the intended addition.
overtimeCents.baseCents + overtimeCents * 10 still multiplies overtime before adding the base amount.10 / 100 evaluate to 0, causing the overtime term to contribute nothing.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
Read the Java 21 1Z0-830 Cheat Sheet on Tech Exam Lexicon, then return to IT Mastery for timed practice.