Java 17 1Z0-829: Packaging and Modules

Topic snapshot

Sample questions

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.

Question 1

Topic: Packaging, Deploying, and Java Platform Module System

A project is compiled on Java 17. The library JAR is a valid modular JAR with module com.acme.lib { exports com.acme.lib; }, and Util.message() is public and returns "ok".

// src/com.acme.app/module-info.java
module com.acme.app {
    requires com.acme.lib;
}

// src/com.acme.app/com/acme/app/Main.java
package com.acme.app;
import com.acme.lib.Util;
public class Main {
    public static void main(String[] args) {
        System.out.println(Util.message());
    }
}

The compile command is:

javac -d out --module-source-path src --class-path lib/com.acme.lib.jar -m com.acme.app

What is the result?

Options:

• A. Compilation succeeds and Main would print ok.

• B. Compilation succeeds only if --source-path src replaces --module-source-path src.

• C. Compilation fails because --module-source-path cannot be used with -m.

• D. Compilation fails; com.acme.lib must be on the module path.

Best answer: D

Explanation: The command compiles a named module, so requires com.acme.lib must resolve a named module. Placing the modular JAR on the class path does not make it available for module resolution.

For modular compilation, --module-source-path tells javac where to find module source trees, while --module-path tells it where to find required named modules. The class path is not used to satisfy a requires directive in module-info.java. In this command, com.acme.app is found in the modular source layout, but com.acme.lib is placed on --class-path, so the compiler cannot resolve the required module. The compile command would need --module-path lib or an equivalent module path entry containing com.acme.lib.jar.

• Runtime output is unreachable because the module graph cannot be resolved at compile time.
• Invalid option claim fails because --module-source-path and -m are meant to work together for modular source compilation.
• Source path swap is wrong because --source-path is for ordinary package source lookup, not modular source layout with -m.

Question 2

Topic: Packaging, Deploying, and Java Platform Module System

An application is organized as named modules and runs successfully from the module path. When the team tries to build a custom runtime image, the command fails:

jlink
  --module-path $JAVA_HOME/jmods:mods:lib
  --add-modules com.acme.app
  --output app-image

Error: automatic module cannot be used with jlink: com.acme.util

The dependency lib/com.acme.util.jar has no module-info.class. Which is the best next fix?

Options:

• A. Use --add-modules ALL-MODULE-PATH.

• B. Add requires java.base to com.acme.app.

• C. Rebuild com.acme.util as an explicit module.

• D. Move com.acme.util.jar to the class path.

Best answer: C

Explanation: The failure is caused by using an automatic module during image creation. A custom runtime image built by jlink is created from resolved named modules, and automatic modules are not accepted as linkable modules.

jlink creates a runtime image by resolving a module graph from the roots named with --add-modules. The modules being linked must be proper named modules, such as JDK modules, JMODs, or modular JARs with a module-info.class. A JAR placed on the module path without a descriptor becomes an automatic module, which may be usable when launching an application but is rejected by jlink.

The practical fix is to use a modular version of the dependency or rebuild it with a valid module-info.java. Changing root modules or adding implicit requirements does not turn an automatic module into an explicit one.

• Implicit base module fails because every module already reads java.base automatically.
• Adding all roots fails because ALL-MODULE-PATH does not make automatic modules linkable.
• Using class path fails because jlink builds a module-based runtime image, not a class path package.

Question 3

Topic: Packaging, Deploying, and Java Platform Module System

A team has compiled a Java 17 application as named modules in a mods directory. The root module is com.orders.app, and its main class is com.orders.app.Main. They need a custom runtime image directory named image that includes the Java runtime pieces needed by the application, so target machines do not need a separate JRE. Which approach creates that image?

Options:

• A. Use jar --create to package the module files into image.

• B. Use jdeps to list modules, then copy them into image.

• C. Use java --module com.orders.app/com.orders.app.Main --output image.

• D. Use jlink with the module path, root module, and --output image.

Best answer: D

Explanation: A Java runtime image is created with jlink. It links the application’s named root module and its resolved module dependencies into an image directory that includes the runtime components needed to launch the application.

The core tool for runtime image creation in JPMS is jlink. For a modular application, you provide a module path containing the application modules and the JDK modules, identify one or more root modules with --add-modules, and specify the destination with --output. jlink then resolves required modules transitively and builds a custom runtime image containing launch tools and the needed modules. A launcher can also be added with --launcher, but it is not the defining step for image creation.

Packaging tools such as jar create archives, and analysis tools such as jdeps report dependencies. They do not produce a linked runtime image.

• JAR packaging fails because a JAR is an archive format, not a linked runtime image containing Java runtime components.
• Dependency analysis fails because jdeps can help discover module dependencies but does not assemble the runtime image.
• Running the module fails because java --module launches an application; it does not create an output image.

Question 4

Topic: Packaging, Deploying, and Java Platform Module System

An application is split into named modules. com.acme.api exports com.acme.spi, which contains public interface FormatterPlugin. Module com.acme.json contains public class com.acme.json.JsonFormatter that implements FormatterPlugin and has a public no-argument constructor. Module com.acme.app calls:

ServiceLoader.load(FormatterPlugin.class).findFirst();

Assume the provider module is resolved at run time and all needed requires com.acme.api; directives are present. Which additional module declarations correctly support service provider loading?

Options:

• A. com.acme.api: uses com.acme.spi.FormatterPlugin;; com.acme.json: provides com.acme.spi.FormatterPlugin with com.acme.json.JsonFormatter;

• B. com.acme.app: uses com.acme.spi.FormatterPlugin;; com.acme.json: provides com.acme.spi.FormatterPlugin with com.acme.json.JsonFormatter;

• C. com.acme.app: provides com.acme.spi.FormatterPlugin with com.acme.json.JsonFormatter;; com.acme.json: uses com.acme.spi.FormatterPlugin;

• D. com.acme.app: requires com.acme.json;; com.acme.json: exports com.acme.json;

Best answer: B

Explanation: JPMS service loading separates the service consumer from the service provider. The module that calls ServiceLoader.load() declares uses, and the module containing the implementation declares provides ... with .... Direct readability or exported packages are not substitutes for service declarations.

In a named module, service loading is described in module-info.java. The service interface normally lives in an exported API package. A consumer module that asks ServiceLoader for implementations declares uses service.Type;. A provider module declares provides service.Type with provider.Implementation;. The provider package does not need to be exported just to make the provider discoverable through ServiceLoader.

Here, com.acme.app is the consumer because it calls ServiceLoader.load(FormatterPlugin.class). com.acme.json is the provider because it contains JsonFormatter. Reversing those roles or relying only on requires and exports does not correctly declare a JPMS service relationship.

• Reversed roles fails because the application consumes the service, while the JSON module provides the implementation.
• Direct dependency fails because requires and exports can expose a class but do not declare it as a service provider.
• Wrong consumer module fails because the API module defines the service type but does not call ServiceLoader in the scenario.

Question 5

Topic: Packaging, Deploying, and Java Platform Module System

An application is split into named modules. JsonFormatter is a public class with a public no-arg constructor that implements com.acme.format.Formatter. All three modules are resolved in the boot layer. The app calls ServiceLoader.load(Formatter.class).findFirst().orElseThrow();, but running it throws ServiceConfigurationError: com.acme.format.Formatter: module com.acme.report does not declare uses.

Current module-info.java snippets:

module com.acme.format.api {
    exports com.acme.format;
}
module com.acme.format.json {
    requires com.acme.format.api;
}
module com.acme.report {
    requires com.acme.format.api;
}

Which change is the best fix so ServiceLoader can discover JsonFormatter without a direct implementation dependency?

Options:

• A. Add only exports com.acme.format.json; to com.acme.format.json.

• B. Add only uses com.acme.format.Formatter; to com.acme.report.

• C. Add only requires com.acme.format.json; to com.acme.report.

• D. Add uses to the app module and provides ... with to the provider module.

Best answer: D

Explanation: JPMS service loading uses module service directives, not exported implementation packages or direct implementation dependencies. The application module must declare that it uses the service type, and the provider module must advertise its implementation with provides ... with. Both are missing from the shown descriptors.

For a named module using ServiceLoader.load(Formatter.class), the caller’s module descriptor must include uses com.acme.format.Formatter;. Otherwise, Java reports the shown ServiceConfigurationError. Also, the implementation is not a service provider merely because its class is present in a resolved module; com.acme.format.json must declare provides com.acme.format.Formatter with com.acme.format.json.JsonFormatter;. The provider package does not need to be exported just for service loading. The key distinction is that requires makes a module readable, while uses and provides define the service relationship.

• Only uses fixes the reported uses error, but JsonFormatter still is not registered as a provider.
• Direct requires adds readability to the implementation module, but service loading is not driven by direct dependencies.
• Exporting the implementation exposes the package, but ServiceLoader relies on provides, and providers may be in non-exported packages.

Question 6

Topic: Packaging, Deploying, and Java Platform Module System

A team compiles a Java 17 modular application. The file lib/util.jar is a modular JAR whose descriptor declares module com.util and exports package com.util.

Project files:

src/com.app/module-info.java
src/com.app/com/app/Main.java

module-info.java contains:

module com.app {
    requires com.util;
}

The compile command fails with error: module not found: com.util:

javac -d out --module-source-path src --class-path lib/util.jar -m com.app

Which is the best next fix?

Options:

• A. Remove requires com.util and rely on imports in Main.

• B. Add src/com.app to the class path.

• C. Put lib/util.jar on the module path, not the class path.

• D. Add --source-path src and keep the current class path.

Best answer: C

Explanation: The application is being compiled as a named module because -m com.app and module-info.java are used. A requires directive must be satisfied by a named module found on the module path, so the modular JAR must be supplied there.

In modular compilation, --module-source-path tells javac where to find the source tree for modules being compiled. Dependencies named in module-info.java, such as requires com.util, are resolved from the module path. The class path is for unnamed/classpath code and does not satisfy a named module dependency. Since lib/util.jar is already a modular JAR, the next fix is to place it on --module-path instead of --class-path, for example by using the JAR or its containing module directory as a module-path entry.

Adding a source path changes where source files are searched, but it does not make a modular dependency readable.

• Class path source fix fails because src/com.app contains sources, not the required compiled named module.
• Plain source path fails because --source-path is not used to resolve requires directives between modules.
• Removing requires fails because a named module must declare readable module dependencies in module-info.java.

Question 7

Topic: Packaging, Deploying, and Java Platform Module System

A Java 17 application is being migrated to JPMS. The application code is packaged as a named module on the module path, but an older library JAR remains on the class path. Which rule explains a common migration failure in this setup?

Options:

• A. Named modules do not read the unnamed module.

• B. Classpath JARs automatically become automatic modules.

• C. Exported packages must also be opened to be compiled against.

• D. module-info.java can declare requires unnamed.

Best answer: A

Explanation: Classes loaded from the class path belong to the unnamed module. A named module on the module path does not read the unnamed module, so leaving a dependency only on the class path can break modular compilation or launch.

JPMS separates code on the module path from code on the class path. A non-modular JAR placed on the module path can become an automatic module, but a JAR left on the class path is part of the unnamed module. Regular named modules cannot declare a dependency on the unnamed module, so their code cannot simply compile against or read those class-path classes as a modular dependency.

A common migration fix is to move the legacy JAR to the module path as an automatic module, or provide a real module descriptor for it. The key distinction is where the JAR is placed: class path means unnamed module; module path can make it a named or automatic module.

• Automatic module confusion fails because automatic modules are created from suitable JARs on the module path, not merely from the class path.
• Invalid directive fails because requires unnamed is not legal syntax in module-info.java.
• Exports versus opens fails because opens is mainly for deep reflection; compile-time access uses exported packages.

Question 8

Topic: Packaging, Deploying, and Java Platform Module System

A library currently uses ordinary packages to separate its API from implementation:

com.acme.orders.api.OrderService
com.acme.orders.internal.SqlOrderRepository

SqlOrderRepository must stay public so other packages inside the library can use it, but client modules must not import it. No reflective access to the internal package is required. Which refactor best enforces this in Java 17?

Options:

• A. Rename the package to com.acme.orders.api.internal.

• B. Create a named module that exports only com.acme.orders.api.

• C. Make SqlOrderRepository a sealed class permitting only OrderService.

• D. Add opens com.acme.orders.internal to the module descriptor.

Best answer: B

Explanation: Package names alone organize code but do not create a module boundary. In JPMS, strong encapsulation comes from a named module descriptor that exports only selected packages, leaving implementation packages unexported.

JPMS strong encapsulation is controlled by module-info.java, not by package naming conventions. A public class in a non-exported package can be used by code inside the same named module, but it is not part of the module’s public API for other modules. Exporting only com.acme.orders.api lets clients compile against OrderService while preventing normal imports of com.acme.orders.internal.SqlOrderRepository from client modules.

The key distinction is that packages provide namespace and package-private access rules; modules define which public packages are readable across module boundaries.

• Package naming fails because internal in a package name is only a convention, not an access rule.
• Opening internals is for reflective access and would weaken run-time encapsulation without making it an intended API.
• Sealed classes control permitted subclasses, not whether another module can import or instantiate a public type.

Question 9

Topic: Packaging, Deploying, and Java Platform Module System

A team is migrating an application but wants com.acme.app to remain a named module. The legacy JAR lib/legacy-csv.jar has no module-info.class; jar --describe-module --file lib/legacy-csv.jar reports the automatic module name legacy.csv.

module com.acme.app {
    requires legacy.csv;
}

javac --module-path mods --class-path lib/legacy-csv.jar \
      -d out --module-source-path src -m com.acme.app
src/com.acme.app/module-info.java:2: error: module not found: legacy.csv

Which change is the best fix?

Options:

• A. Put legacy-csv.jar on the module path.

• B. Add exports org.legacy; to com.acme.app.

• C. Remove module-info.java from com.acme.app.

• D. Keep the JAR on the class path and add requires unnamed;

Best answer: A

Explanation: The compile error occurs because legacy.csv is not observable as a named module. A non-modular JAR on the class path belongs to the unnamed module; it becomes an automatic module only on the module path.

JPMS treats placement as significant during migration. A modular application with module-info.java is a named module. A regular JAR without a descriptor is not automatically a named module just because it exists; on the class path it is part of the unnamed module, and a named module cannot use requires to name it there. Placing the JAR on the module path lets JPMS derive the automatic module legacy.csv, which can then satisfy requires legacy.csv;.

The key takeaway is that automatic module status is based on being a non-modular JAR on the module path, not merely on being a legacy JAR.

• Class path assumption fails because class path JARs are in the unnamed module, not automatic named modules.
• Exports direction fails because exports exposes packages from com.acme.app; it does not make another JAR readable.
• Removing the descriptor would abandon the requirement that the application remain a named module.

Question 10

Topic: Packaging, Deploying, and Java Platform Module System

A modular application has these descriptors. com.acme.app contains code that imports com.acme.internal.Config and does not use reflection.

module com.acme.util {
    opens com.acme.internal;
}

module com.acme.app {
    requires com.acme.util;
}

Compilation fails because com.acme.internal is not visible to com.acme.app. Which proposed change fixes the problem?

Options:

• A. Create package com.acme.internal in both modules.

• B. Add opens com.acme.internal to com.acme.app; to com.acme.util.

• C. Replace opens with exports in com.acme.util.

• D. Change requires to requires transitive in com.acme.app.

Best answer: C

Explanation: The issue is package accessibility in JPMS. opens permits deep reflection but does not make public types available for normal imports and compilation. Since com.acme.app already reads com.acme.util, the needed change is to export the package from com.acme.util.

JPMS separates readability from accessibility. The requires com.acme.util; directive lets com.acme.app read the utility module, but code in com.acme.app can access only packages that com.acme.util exports. An opens directive is for reflective access, such as frameworks using reflection on members; it does not support ordinary source-code imports of public classes.

requires transitive would pass readability to downstream modules, but it would not export a hidden package. Creating the same package in both modules risks a split-package conflict rather than solving accessibility.

• Transitive readability fails because it affects modules that read com.acme.app, not whether com.acme.util exports the package.
• Qualified opens fails because opening a package still supports reflection, not normal compile-time access.
• Duplicate package fails because putting the same package in multiple resolved modules creates a split-package problem.

Continue with full practice

Use the Java 17 1Z0-829 Practice Test page for the full IT Mastery route, mixed-topic practice, timed mock exams, explanations, and web/mobile app access.

Try Java 17 1Z0-829 on Web View Java 17 1Z0-829 Practice Test

Related focused pages

• Free Java 17 1Z0-829 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
• Accessing Databases Using JDBC
• Implementing Localization
• Logging and Annotations

Free review resource

Read the Java 17 1Z0-829 Cheat Sheet on Tech Exam Lexicon, then return to IT Mastery for timed practice.