The correct approach is to refactor the code to use public APIs instead of reflecting on String's internal fields. This resolves the InaccessibleObjectException because Java 9’s module system strictly encapsulates internal packages like java.lang by default, preventing reflection on private members of core classes. Attempting to access String’s private byte[] value field triggers the error, as the unnamed module lacks the required opens directive. On the Oracle Java Foundations 1Z0-811 exam, this question tests your understanding of the module system’s impact on reflection—a common trap is assuming JVM flags like --add-opens are always viable, but here the server restrictions force a code-level fix. The core lesson is that public APIs (e.g., String.getBytes() or charAt()) are the only portable solution. Memory tip: “Reflection on private fields? Refactor to public shields.”
1Z0-811 Exception Handling and Development Tools Practice Question
This 1Z0-811 practice question tests your understanding of exception handling and development tools. The scenario asks you to isolate a root cause — eliminate options that address a different problem before choosing. After answering, compare your reasoning against the explanation and wrong-answer breakdown below. Once you have made your selection, read the full explanation to reinforce the concept and understand why each distractor is designed to mislead on exam day.
You are a Java developer at a financial firm. The application processes transactions from a queue. The team recently migrated from Java 8 to Java 11. After the migration, the application intermittently throws an exception: 'java.lang.reflect.InaccessibleObjectException: Unable to make field private final byte[] java.lang.String.value accessible: module java.base does not 'opens java.lang' to unnamed module'. This error occurs when the application tries to use reflection to access private fields of String objects for serialization. The application runs on a server where you cannot modify the JVM startup scripts. However, you can modify the application code and the module-info.java file. You need to resolve the exception without breaking existing functionality. Which approach should you take?
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Refactor the code to use public APIs instead of reflecting on String's internal fields.
Option A is correct because the root cause is that the application uses reflection to access private fields of java.lang.String, which is prohibited in Java 9+ by default due to module system encapsulation. Refactoring to use public APIs (e.g., String.getBytes(), String.charAt()) eliminates the need for reflection entirely, resolving the InaccessibleObjectException without requiring JVM flags or module declarations, and preserves compatibility with Java 11.
Key principle: Answer the scenario, not the keyword: identify the specific constraint before choosing the most familiar-sounding option.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
✓
Refactor the code to use public APIs instead of reflecting on String's internal fields.
Why this is correct
This avoids the module access issue entirely.
Related concept
Read the scenario before looking for a memorised answer.
✗
Add --add-opens java.base/java.lang=ALL-UNNAMED to the JVM command line.
Why it's wrong here
You cannot modify JVM startup scripts per the scenario.
✗
Use sun.misc.Unsafe to access the String field directly.
Why it's wrong here
Unsafe still requires reflection and is not a solution.
✗
Add 'opens java.lang;' to the module-info.java file.
Why it's wrong here
You cannot open java.lang from your module; it's a system module.
Common exam traps
Common exam trap: answer the scenario, not the keyword
Oracle often tests the misconception that you can fix module-access errors by adding 'opens' directives in your own module-info.java, but you cannot open packages belonging to other modules (like java.base) from your module descriptor.
Trap categories for this question
Scenario analysis trap
You cannot modify JVM startup scripts per the scenario.
Detailed technical explanation
How to think about this question
The Java Platform Module System (JPMS) introduced in Java 9 enforces strong encapsulation by default, preventing reflection access to internal APIs of core modules like java.base. The InaccessibleObjectException specifically occurs when code tries to set accessible true on a reflected field of a class in a module that does not open its package. Refactoring to use public APIs is the only sustainable solution that aligns with modern Java best practices and avoids reliance on internal implementation details that may change across JDK versions.
KKey Concepts to Remember
Read the scenario before looking for a memorised answer.
Find the constraint that changes the correct option.
Eliminate answers that are true in general but not in this case.
TExam Day Tips
→Watch for words such as best, first, most likely and least administrative effort.
→Review why wrong options are wrong, not only why the correct option is correct.
Key takeaway
Answer the scenario, not the keyword: identify the specific constraint before choosing the most familiar-sounding option.
Real-world example
How this comes up in practice
A small business has 20 workstations on the 192.168.1.0/24 network and one public IP from its ISP. The router uses PAT (NAT overload) so all 20 devices share one public address using different source ports. NAT questions test whether you understand the four address terms and which direction each translation applies.
What to study next
Got this wrong? Here's your next step.
Identify which exam domain this question belongs to, review the core concept, then practise similar questions from the same domain.
Exception Handling and Development Tools — This question tests Exception Handling and Development Tools — Read the scenario before looking for a memorised answer..
What is the correct answer to this question?
The correct answer is: Refactor the code to use public APIs instead of reflecting on String's internal fields. — Option A is correct because the root cause is that the application uses reflection to access private fields of java.lang.String, which is prohibited in Java 9+ by default due to module system encapsulation. Refactoring to use public APIs (e.g., String.getBytes(), String.charAt()) eliminates the need for reflection entirely, resolving the InaccessibleObjectException without requiring JVM flags or module declarations, and preserves compatibility with Java 11.
What should I do if I get this 1Z0-811 question wrong?
Identify which exam domain this question belongs to, review the core concept, then practise similar questions from the same domain.
What is the key concept behind this question?
Read the scenario before looking for a memorised answer.
About these practice questions
Courseiva creates original exam-style practice questions with explanations and wrong-answer analysis. It does not publish real exam questions, exam dumps, or protected exam content. Learn why practice questions differ from exam dumps →
Share a tip, memory trick, or ask about the reasoning behind this question. Do not post real exam questions, leaked content, braindumps, or copyrighted exam material. Comments are moderated and may be removed without notice.
This 1Z0-811 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-811 exam.
Question Discussion
Share a tip, memory trick, or ask about the reasoning behind this question. Do not post real exam questions, leaked content, braindumps, or copyrighted exam material. Comments are moderated and may be removed without notice.
Sign in to join the discussion.