1Z0-829 Java Platform Overview and Packaging Practice Question
An organization has a monolithic Java application built with Java 8 and deployed on a traditional classpath. They are migrating to Java 17 and want to use the module system to improve encapsulation. They have a jar file 'legacy.jar' that contains packages under 'com.legacy' and does not have a module-info.class. Which approach should they take to allow other modules to depend on this jar?
⚠ Common exam trap
Test-takers frequently confuse the classpath (unnamed module) with the module path (automatic module) and incorrectly assume that placing a JAR on the classpath allows named modules to depend on it, when in fact only automatic modules on the module path can be referenced by 'requires' in module-info.java.
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
✓
Place the jar on the module path; it becomes an automatic module.
When a JAR file without a module-info.class is placed on the module path, Java treats it as an automatic module. This allows other modules to depend on it by name (derived from the JAR filename) and grants it access to all other modules, effectively bridging the gap between the classpath and the module system during migration.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Add a module-info.class file to the jar using jar tool.
Why it's wrong here
Adding a `module-info.class` to `legacy.jar` would require the jar to declare its dependencies and exported packages in a module descriptor, but the jar's code was never written with the module system in mind and likely contains split packages or implicit access to internal APIs that would cause module-resolution failures at runtime. This approach is tempting because it is the standard way to turn a normal jar into a named module, and it would be correct if the jar's source code were already compatible with Java's module system and simply lacked the descriptor.
- ✓
Place the jar on the module path; it becomes an automatic module.
Why this is correct
Automatic modules are derived from jar files on the module path that lack module-info.class.
- ✗
Place the jar on the classpath; it becomes an unnamed module.
Why it's wrong here
Unnamed modules have no defined module name and cannot be depended upon by named modules.
- ✗
Use jmod tool to convert the jar into a JMOD file.
Why it's wrong here
jmod is for creating JMOD files, not for handling existing jars; the jar would still need a module descriptor.
Go deeper
Related to this question
About these practice questions
This 1Z0-829 question is part of Courseiva's 513-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. 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.