Try 10 focused Java 21 1Z0-830 questions on Packaging and Deploying Java Code, 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 | Packaging and Deploying Java Code |
| Blueprint weight | 7% |
| Page purpose | Focused sample questions before returning to mixed practice |
Use this page to isolate Packaging and Deploying Java Code 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: 7% 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: Packaging and Deploying Java Code
A library is delivered in two ways. The old JAR is placed on the class path and contains a public class com.shop.internal.Rules. The new version is a named module that also contains that public class, and com.shop.client has requires com.shop.core;:
module com.shop.core {
exports com.shop.api;
}
Which statement best compares ordinary package organization with strong encapsulation for normal source-code access?
Options:
A. The class-path JAR permits importing Rules, but the named module blocks it.
B. Both deliveries permit access because Rules is public and the module is required.
C. The named module permits access if com.shop.internal is opened instead of exported.
D. Both deliveries block access because internal is a special package name.
Best answer: A
Explanation: Ordinary packages organize names and support package-private access, but they do not hide public types on the class path. In JPMS, a named module strongly encapsulates packages that are not exported, so other modules cannot normally import public types from those packages.
Strong encapsulation is a module-system feature, not a package-naming convention. In a named module, only public types in exported packages are accessible to other modules for normal source-code use. A requires directive gives readability to the required module, but it does not expose every package inside it. By contrast, a plain class-path JAR with a package named com.shop.internal still allows other code to import a public class from that package if the JAR is visible. The closest trap is confusing opens with exports: opens supports reflective access, while exports controls ordinary access to public types.
internal has no built-in Java access-control meaning.opens is for reflection, not normal imports and static access.Topic: Packaging and Deploying Java Code
A team is migrating an application to JPMS. com.store.app is an explicit named module launched from the module path. billing-api.jar has no module descriptor, has Automatic-Module-Name: billing.api, and is on the module path. legacy-util.jar has no descriptor and remains on the class path; only billing-api.jar uses it internally. Which entry correctly belongs in com.store.app’s module declaration?
Options:
A. requires legacy.util;
B. requires ALL-UNNAMED;
C. requires billing.api;
D. Omit requires because descriptorless JARs are unreadable.
Best answer: C
Explanation: billing-api.jar becomes an automatic module because it is on the module path without a descriptor. Its stable module name comes from Automatic-Module-Name, so an explicit named module can use requires billing.api;.
JPMS distinguishes where code is placed during migration. com.store.app is an explicit named module because it has module-info.java. billing-api.jar is an automatic module because it is a non-modular JAR on the module path, and its module name is billing.api. legacy-util.jar is in the unnamed module because it remains on the class path. A named module can require the automatic module, but it cannot declare a dependency on the unnamed module in module-info.java. Automatic modules help migration by being able to read class-path code, so billing-api.jar can keep its internal dependency while the app requires only billing.api.
legacy-util.jar is in the unnamed module and cannot be named in a requires directive.module-info.java.Topic: Packaging and Deploying Java Code
A team is migrating an application to the Java Platform Module System. The application is now a named module:
module com.shop.app {
requires legacy.utils;
}
The legacy library JAR has no module-info.class, but its manifest contains Automatic-Module-Name: legacy.utils. The compile command places that JAR only on the class path, and compilation fails:
error: module not found: legacy.utils
What is the best next fix?
Options:
A. Remove requires legacy.utils; from the descriptor.
B. Add requires java.base; to the descriptor.
C. Add exports com.legacy; to com.shop.app.
D. Put legacy-utils.jar on the module path.
Best answer: D
Explanation: The JAR is currently on the class path, so it is part of the unnamed module. A named module cannot satisfy a requires directive from the unnamed module. Moving the JAR to the module path makes it an automatic module named legacy.utils.
During migration, a JAR without module-info.class behaves differently depending on where it is placed. On the class path, it belongs to the unnamed module and is not resolved as a named dependency. On the module path, it becomes an automatic module; because the manifest declares Automatic-Module-Name: legacy.utils, the named module com.shop.app can require it with requires legacy.utils;. The key distinction is class path means unnamed module, while module path can create automatic modules for legacy JARs.
requires fails because the named module would still not read the legacy library through normal module resolution.com.legacy is wrong because com.shop.app cannot export a package it does not contain.java.base is unnecessary because java.base is required implicitly by every module.Topic: Packaging and Deploying Java Code
A team compiles these two Java 21 modules together using a valid module source path. What is the result?
// module reports
module reports {
opens com.example.reports.internal;
}
package com.example.reports.internal;
public class Audit {
public static String id() { return "A"; }
}
// module app
module app {
requires reports;
}
package com.example.app;
import com.example.reports.internal.Audit;
public class Main {
public static void main(String[] args) {
System.out.println(Audit.id());
}
}
Options:
A. The program compiles and prints A.
B. Compilation fails because the package is not exported.
C. Compilation fails because the modules create a split package.
D. Compilation fails because app is missing requires reports.
Best answer: B
Explanation: The decisive distinction is exports versus opens in JPMS. The app module has readability because it requires reports, but it cannot directly import a public type from a package that reports only opens.
In the Java Platform Module System, requires gives one module readability to another module, but public types are accessible only from exported packages. An opens directive is for deep reflective access at run time; it does not allow normal source code in another module to import and use that package. Here, app can read reports, but com.example.reports.internal is not exported, so the direct import of Audit fails at compile time.
The closest trap is treating opens like exports; they solve different access problems.
module app already declares requires reports.main can run.Topic: Packaging and Deploying Java Code
Assume all named modules exist and export any service or API packages needed by com.acme.orders. A team is writing module-info.java for com.acme.orders with these requirements:
com.acme.orders.api.com.acme.money, and consumers should not separately require that module.com.acme.orders.model is needed only for deep reflection by module com.acme.json.java.logging and loads com.acme.payments.spi.PaymentProvider services.Which declaration is correct?
Options:
- B. ```java
module com.acme.orders {
requires java.logging;
requires com.acme.payments;
requires com.acme.money;
exports com.acme.orders.api;
opens com.acme.orders.model to com.acme.json;
uses com.acme.payments.spi.PaymentProvider;
}
- D. ```java
module com.acme.orders {
requires java.logging;
requires com.acme.payments;
requires transitive com.acme.money;
opens com.acme.orders.api;
exports com.acme.orders.model to com.acme.json;
uses com.acme.payments.spi.PaymentProvider;
}
Best answer: C
Explanation: The public API package needs exports, while the model package needs opens because it is for deep reflection rather than normal compilation access. Since com.acme.money appears in public API signatures, requires transitive lets downstream modules read it automatically.
JPMS separates compile-time accessibility from reflective access. exports com.acme.orders.api makes the public API available to other modules. opens com.acme.orders.model to com.acme.json permits deep reflection by the named module without making the package generally importable. requires transitive com.acme.money is appropriate because the dependency is part of the exported API surface, so modules requiring com.acme.orders also read com.acme.money. The uses directive names a service type, not a module, for ServiceLoader discovery.
The key distinction is that exports is for normal access to public types, while opens is for reflective access.
com.acme.money.uses must name the service interface type, not the module containing it.Topic: Packaging and Deploying Java Code
All files are compiled and run as named Java 21 modules. Imports are not material because fully qualified names are used. What is the result?
// module com.tools/module-info.java
module com.tools {
exports com.tools.api;
}
// module com.tools/com/tools/internal/Code.java
package com.tools.internal;
public class Code { public static String value() { return "ok"; } }
// module com.tools/com/tools/api/Facade.java
package com.tools.api;
public class Facade {
public static String call() { return com.tools.internal.Code.value(); }
}
// module com.app/module-info.java
module com.app { requires com.tools; }
// module com.app/com/app/Main.java
package com.app;
public class Main {
public static void main(String[] args) {
System.out.print(com.tools.api.Facade.call() + " ");
System.out.print(com.tools.internal.Code.value());
}
}
Options:
A. It prints ok ok.
B. Compilation fails: com.tools.internal is not exported.
C. Compilation fails in Facade.call().
D. It throws IllegalAccessError at runtime.
Best answer: B
Explanation: JPMS strong encapsulation is based on module exports, not package naming conventions. A public type in a non-exported package can be used inside its own module, but another module cannot directly refer to it. The direct reference from com.app to com.tools.internal.Code is rejected at compile time.
In a named module, public is not enough for access from another module. The package containing the public type must also be exported by the supplying module. Here, com.tools exports only com.tools.api, so com.app can call Facade. However, com.tools.internal is not exported, even though Code is public and its package name is just an ordinary package name. Code inside com.tools may still use its own non-exported package, so Facade.call() is valid.
The key distinction is that package organization is a naming structure, while JPMS exports create enforceable module boundaries.
com.tools can access other packages in the same module.Topic: Packaging and Deploying Java Code
A reporting application is split into two named modules. Each snippet below represents a separate source file in a location matching its module and package declaration, and the imports shown are complete. What is the result of compiling and running reports/reports.Main?
// module orders.core
module orders.core { exports orders.api; }
// in module orders.core
package orders.api;
public class Order { public String id() { return "O1"; } }
// in module orders.core
package orders.internal;
public class Helper { public static String suffix() { return "-ok"; } }
// module reports
module reports { requires orders.core; }
// in module reports
package reports;
import orders.api.Order;
import orders.internal.Helper;
public class Main {
public static void main(String[] args) {
System.out.println(new Order().id() + Helper.suffix());
}
}
Options:
A. It prints O1-ok.
B. It compiles, then throws IllegalAccessError.
C. Compilation fails because orders.core must require reports.
D. Compilation fails because orders.internal is not exported.
Best answer: D
Explanation: The requires orders.core directive gives reports readability to the orders.core module. However, readability alone does not expose every package in that module; only exported packages are accessible at compile time.
In JPMS, named modules perform both a readability check and an accessibility check. The reports module can read orders.core because it declares requires orders.core, so orders.api.Order is accessible because orders.api is exported. The orders.internal.Helper class is public, but its package is not exported by orders.core, so code in reports cannot import or refer to it. This is a compile-time error, not a runtime access failure. Public top-level classes are accessible across modules only when their package is exported to the reading module.
requires does not expose non-exported packages.Topic: Packaging and Deploying Java Code
A library module com.shop.model contains package com.shop.domain. Two named modules use it:
com.shop.app imports com.shop.domain.Order and must compile against its public API.com.json.bind uses reflection to access non-public members in com.shop.domain.No other modules should receive these permissions. Which module-info.java configuration for com.shop.model satisfies the requirements?
Options:
A. opens com.shop.domain to com.shop.app; and exports com.shop.domain to com.json.bind;
B. exports com.shop.domain to com.shop.app; and opens com.shop.domain to com.json.bind;
C. exports com.shop.domain to com.shop.app, com.json.bind; only
D. opens com.shop.domain to com.shop.app, com.json.bind; only
Best answer: B
Explanation: JPMS separates ordinary API access from deep reflection access. exports lets another module compile against and use public types in a package, while opens allows reflective access to non-public members at run time.
In a module declaration, exports is for normal access to public API members from another module. Since com.shop.app imports Order, com.shop.domain must be exported to that module. Deep reflection into non-public members is controlled by opens, not by exports, so the package must be opened to com.json.bind. Using qualified directives limits each permission to the named target module, satisfying the requirement that no other modules receive access.
com.json.bind does not allow deep reflection into non-public members.com.shop.app.Topic: Packaging and Deploying Java Code
A Java 21 application is being modularized. Module com.acme.reports currently declares:
module com.acme.reports {
requires com.acme.model;
exports com.acme.reports.api;
}
Its public API uses com.acme.model.Customer in method signatures. Its implementation loads the public service interface com.acme.spi.Formatter using ServiceLoader, and module com.acme.serializer must reflectively access non-public members in com.acme.reports.internal. Consumers should compile by requiring only com.acme.reports. Which replacement module-info.java is the best fix?
Options:
- B. ```java
module com.acme.reports {
requires transitive com.acme.model;
requires com.acme.spi;
exports com.acme.reports.api;
opens com.acme.reports.internal to com.acme.serializer;
uses com.acme.spi.Formatter;
}
- D. ```java
module com.acme.reports {
requires com.acme.model;
requires com.acme.spi;
exports com.acme.reports.api;
opens com.acme.reports.internal to com.acme.serializer;
uses com.acme.spi.Formatter;
}
Best answer: B
Explanation: The reports module must make its API package available at compile time and give consumers implied readability to the model module. It also needs a qualified opens directive for deep reflection and a uses directive for ServiceLoader.
In JPMS, exports makes public types in a package accessible to other modules at compile time. If an exported API exposes types from another module, requires transitive is appropriate so downstream modules that require com.acme.reports can also read com.acme.model. Deep reflective access to non-public members is controlled by opens, and a qualified opens ... to ... limits that access to the named module. ServiceLoader clients should declare uses for the service interface, and the module must read the module containing that interface. The key distinction is that exports supports ordinary compile-time access, while opens supports reflection.
com.acme.reports.exports does not grant deep reflective access to non-public members.opens alone does not make the public API available for normal compile-time use.Topic: Packaging and Deploying Java Code
A library JAR named acme-util-2.0.jar contains ordinary class files and this manifest entry, but it does not contain module-info.class:
Automatic-Module-Name: com.acme.util
The JAR is placed on the module path of a Java 21 application. Which statement is true?
Options:
A. It is an explicit module because the manifest names it.
B. Only packages listed in the manifest are exported.
C. It is an automatic module named com.acme.util.
D. It must be placed on the class path to be usable.
Best answer: C
Explanation: A JAR is modular only when it contains a module descriptor, normally module-info.class. Without that descriptor, a JAR on the module path is treated as an automatic module, and the manifest entry can provide its module name.
In Java 21, a non-modular JAR placed on the module path is not converted into an explicit module. It becomes an automatic module. If the JAR manifest contains Automatic-Module-Name, that value is used as the module name instead of deriving a name from the file name. Automatic modules export all their packages, which helps migration from class-path libraries to named modules.
The key distinction is that a manifest module name improves stability, but it does not replace a real module descriptor.
Automatic-Module-Name names the automatic module but does not create an explicit module descriptor.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.