1Z0-829 Practice Question: Handling Date, Time, Text, Numeric and Boolean Values
A financial application uses Java SE 17 with a custom date format. The requirement is to parse strings like "2023-12-31T23:59:59.999Z" into an Instant. The existing code uses SimpleDateFormat with pattern "yyyy-MM-dd'T'HH:mm:ss.SSS'Z'" and then calls parse(). It works fine in single-threaded testing, but in production under load, intermittent parsing failures occur with DateTimeParseException or wrong values. The application is multi-threaded and reuses the same formatter instance. Which single change should be made to fix the issue while maintaining performance?
⚠ Common exam trap
Test-takers frequently choose `ThreadLocal<SimpleDateFormat>` (Option B) because it technically fixes the thread-safety issue, but they overlook that the modern `java.time` API is the recommended, simpler, and more performant solution for Java SE 17, and that the exam expects you to prefer the new API over patching the old one.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Replace SimpleDateFormat with DateTimeFormatter.ISO_INSTANT and use Instant.from()
`SimpleDateFormat` is not thread-safe, and reusing a single instance across multiple threads causes race conditions leading to parsing failures. Replacing it with `DateTimeFormatter.ISO_INSTANT` (which is immutable and thread-safe) and using `Instant.from()` directly parses the ISO 8601 string without any synchronization overhead, maintaining performance while fixing the concurrency bug.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Wrap the parse call in a synchronized block
Why it's wrong here
Thread-safe but causes contention, reducing performance.
- ✗
Use a ThreadLocal<SimpleDateFormat> to give each thread its own instance
Why it's wrong here
A ThreadLocal<SimpleDateFormat> eliminates shared mutable state between threads, which would fix the thread-safety issue if the requirement were to continue using SimpleDateFormat. However, the stem specifies parsing into an Instant, and SimpleDateFormat cannot produce an Instant directly—it produces a java.util.Date, which lacks nanosecond precision and the UTC context that Instant requires. The correct fix is to switch to java.time.format.DateTimeFormatter with a pattern like "yyyy-MM-dd'T'HH:mm:ss.SSSX" and call parse(CharSequence, Instant::from), which is inherently thread-safe and yields an Instant. This option is tempting because ThreadLocal is a standard workaround for non-thread-safe SimpleDateFormat in legacy code, and it would work if the target type were Date rather than Instant.
- ✓
Replace SimpleDateFormat with DateTimeFormatter.ISO_INSTANT and use Instant.from()
Why this is correct
Thread-safe and correct for ISO 8601.
- ✗
Create a new SimpleDateFormat instance for each parse call
Why it's wrong here
Avoids thread safety but creates many objects, hurting performance.
Go deeper
Related to this question
About these practice questions
One of 513 original 1Z0-829 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This 1Z0-829 practice question is part of Courseiva's free Oracle certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the 1Z0-829 exam.