Free Java 21 1Z0-830 Practice Questions: Packaging and Deploying Java Code

Topic snapshot

Sample questions

These are original IT Mastery practice questions aligned to this topic area. They are not official Oracle questions, copied live-exam content, or exam dumps. Use them to preview question style and explanation depth before continuing with topic drills, mixed sets, and timed mocks in IT Mastery.

Question 1

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.

• Special package name fails because internal has no built-in Java access-control meaning.
• Public plus requires fails because module readability does not expose unexported packages.
• Opened package fails because opens is for reflection, not normal imports and static access.

Question 2

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.

• Classpath dependency fails because legacy-util.jar is in the unnamed module and cannot be named in a requires directive.
• ALL-UNNAMED is a command-line target in some options, not a valid module name in module-info.java.
• Descriptorless unreadable is wrong because a descriptorless JAR on the module path becomes an automatic module.

Question 3

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.

• Removing requires fails because the named module would still not read the legacy library through normal module resolution.
• Exporting com.legacy is wrong because com.shop.app cannot export a package it does not contain.
• Requiring java.base is unnecessary because java.base is required implicitly by every module.

Question 4

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.

• Missing dependency is not the issue because module app already declares requires reports.
• Split package does not apply because the two modules do not contain the same package name.
• Runtime access is not reached because ordinary compilation fails before main can run.

Question 5

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:

• Its public API package is com.acme.orders.api.
• Public API signatures use types from module 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.
• The module logs with java.logging and loads com.acme.payments.spi.PaymentProvider services.

Which declaration is correct?

Options:

• A. ```java module com.acme.orders { requires java.logging; requires com.acme.payments; requires transitive com.acme.money; exports com.acme.orders.api; opens com.acme.orders.model to com.acme.json; uses com.acme.payments; }

- 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;
}

• C. ```java module com.acme.orders { requires java.logging; requires com.acme.payments; requires transitive 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.

• Plain requires fails because consumers of the exported API would not automatically read com.acme.money.
• Swapped access directives fails because opening the API does not export it, and exporting the model does not allow deep reflection.
• Module as service fails because uses must name the service interface type, not the module containing it.

Question 6

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.

• Public class assumption fails because a public top-level class in a named module is still inaccessible if its package is not exported.
• Internal module use is valid because code inside com.tools can access other packages in the same module.
• Runtime failure is the wrong phase because ordinary direct access to a non-exported package is rejected by the compiler.

Question 7

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.

• Readable means visible fails because requires does not expose non-exported packages.
• Reverse dependency is unnecessary; the provider module does not need to require its consumer.
• Runtime access error is not reached because the compiler rejects the non-exported package access.

Question 8

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.

• Export only fails because exporting to com.json.bind does not allow deep reflection into non-public members.
• Open only fails because opening a package does not make its public types available for compile-time imports by com.shop.app.
• Reversed directives fail because the app needs exported API access, while the binder needs opened reflective access.

Question 9

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:

• A. ```java module com.acme.reports { requires transitive com.acme.model; requires com.acme.spi; opens com.acme.reports.api; opens com.acme.reports.internal to com.acme.serializer; uses com.acme.spi.Formatter; }

- 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;
}

• C. ```java module com.acme.reports { requires transitive com.acme.model; requires com.acme.spi; exports com.acme.reports.api; exports 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.

• Plain requires fails because consumers would not get implied readability to the model module through com.acme.reports.
• Exporting internals fails because exports does not grant deep reflective access to non-public members.
• Opening the API fails because opens alone does not make the public API available for normal compile-time use.

Question 10

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.

• Manifest confusion fails because Automatic-Module-Name names the automatic module but does not create an explicit module descriptor.
• Class path only fails because non-modular JARs can be placed on the module path as automatic modules.
• Selective exports fails because automatic modules export all packages, not only packages listed in the manifest.

Continue in the web app

Use IT Mastery for interactive Java 21 1Z0-830 practice with mixed sets, timed mocks, topic drills, explanations, and progress tracking.

Try Java 21 1Z0-830 on Web

Related focused pages

• Free Java 21 1Z0-830 Full-Length Practice Exam
• Core Value Types
• Controlling Program Flow
• Object-Oriented Java
• Handling Exceptions
• Working with Arrays and Collections
• Streams and Lambdas
• Managing Concurrent Code Execution
• Using Java I/O API
• Implementing Localization
• Logging and Annotations