Courseiva

CCNA Java Platform Overview and Packaging Questions

69 questions · Java Platform Overview and Packaging · All types, answers revealed

Practice these questionsDomain overviewAll questions
1
MCQhard

A team has a multi-release JAR that supports both Java 11 and Java 17. They want to ensure that when running on Java 17, the version-specific classes in META-INF/versions/17 are used. Which condition must be true?

A.The JAR must have a module-info.class in the root
B.The JAR must be placed on the module path
C.The JAR must be created using the --multi-release 17 option
D.The manifest must contain 'Multi-Release: true'
AnswerD

The manifest entry is required to activate multi-release behavior.

Why this answer

Option D is correct because the Java runtime checks for the `Multi-Release: true` entry in the JAR's manifest file to enable multi-release JAR functionality. Without this manifest attribute, the JVM ignores versioned directories under `META-INF/versions/` and uses only the root classes, even if the JAR was compiled with `--multi-release 17`.

Exam trap

Oracle often tests the misconception that the `--multi-release` compiler or jar tool option alone enables version selection at runtime, when in fact the manifest entry `Multi-Release: true` is the sole runtime trigger.

How to eliminate wrong answers

Option A is wrong because a `module-info.class` in the root is required for modular JARs but is not a condition for multi-release JAR behavior; the runtime resolves version-specific classes based on the manifest, not module descriptors. Option B is wrong because multi-release JARs work correctly on both the class path and module path; placing the JAR on the module path is not a prerequisite for version-specific class loading. Option C is wrong because the `--multi-release 17` flag is used at JAR creation time to embed versioned classes, but the runtime behavior depends solely on the manifest entry `Multi-Release: true`; without it, the JVM will not activate version selection.

Practice this question →
2
MCQmedium

A company deploys a Java 17 application on a server with a custom runtime image created by jlink. The application uses the Java logging API (java.util.logging). The server administrator notices that the image size is approximately 45 MB. They need to reduce it further. Which jlink option would help exclude unnecessary locale data?

A.--include-locales en_US
B.--compress=2
C.--strip-debug
D.--no-header-files
AnswerA

Using --include-locales with a limited set includes only those locales, excluding others and reducing the image size.

Why this answer

Option A is correct because the `--include-locales` option in jlink allows you to specify which locale data to include in the custom runtime image. By default, jlink includes all locale data, which can significantly increase image size. Using `--include-locales en_US` restricts the image to only US English locale data, reducing unnecessary bloat for applications that do not require multiple locales.

Exam trap

The trap here is that candidates may confuse size-reduction options like compression or stripping debug with the specific need to exclude locale data, leading them to choose `--compress=2` or `--strip-debug` instead of the correct `--include-locales` option.

How to eliminate wrong answers

Option B is wrong because `--compress=2` applies ZIP compression to the image's resources, which reduces size but does not specifically exclude locale data; it compresses all resources, including locale data that may still be present. Option C is wrong because `--strip-debug` removes debug information from the image, which reduces size but has no effect on locale data inclusion. Option D is wrong because `--no-header-files` excludes header files (used for native development) from the image, which does not impact locale data.

Practice this question →
3
Multi-Selecthard

Which THREE statements about the jpackage tool are true?

Select 3 answers
A.jpackage requires an existing JRE to create a runtime image.
B.jpackage uses the Java Packager library.
C.jpackage can create native installers for Windows, macOS, and Linux.
D.jpackage can bundle a JVM with the application.
E.jpackage can use a pre-built runtime image created by jlink.
AnswersC, D, E

jpackage supports all major operating systems.

Why this answer

Option C is correct because the jpackage tool is designed to create native installers for Windows (e.g., .exe/.msi), macOS (e.g., .dmg), and Linux (e.g., .deb/.rpm). This is a core feature of jpackage, which replaces the older Java Packager and allows developers to distribute self-contained applications with platform-specific packaging formats.

Exam trap

The trap here is that candidates often confuse jpackage with the deprecated Java Packager (javapackager) or assume it requires an external JRE, when in fact jpackage is a self-contained tool that can generate runtime images and native installers without external dependencies.

Practice this question →
4
MCQeasy

A Java application is developed using Java SE 17. It uses only standard Java APIs and no external libraries. The application runs without errors in the development environment. When deploying to a production server, which minimal Java environment is sufficient?

A.Java compiler (javac)
B.Java Virtual Machine (JVM) only
C.Java Development Kit (JDK)
D.Java Runtime Environment (JRE)
AnswerD

JRE provides JVM and all necessary libraries to run Java applications.

Why this answer

The correct answer is D because a Java application compiled into bytecode (`.class` files) requires only the Java Runtime Environment (JRE) to execute. The JRE includes the Java Virtual Machine (JVM), core libraries, and supporting files, but not development tools like the compiler. Since the application is already compiled and uses only standard APIs, no additional tools are needed at runtime.

Exam trap

The trap here is that candidates confuse the JVM with the JRE, thinking a standalone JVM can run Java applications, but the JVM requires the runtime libraries packaged in the JRE to resolve standard classes like `java.lang.String`.

How to eliminate wrong answers

Option A is wrong because the Java compiler (javac) is a development tool used to compile source code into bytecode; it is not needed to run an already-compiled application. Option B is wrong because a JVM alone is insufficient — the JRE includes the JVM plus essential runtime libraries (e.g., java.lang, java.util) that the application depends on; a standalone JVM without these libraries cannot execute standard Java code. Option C is wrong because the Java Development Kit (JDK) includes the JRE plus development tools (compiler, debugger, etc.), which are unnecessary for running a pre-compiled application and add overhead.

Practice this question →
5
MCQmedium

A company has a legacy application consisting of multiple JAR files that run on Java 11. They plan to migrate to Java 17 and modularize the application using JPMS. However, some third-party libraries do not provide module-info.class files. What is the best approach to ensure the application can be modularized while maintaining compatibility with these libraries?

A.Create a module-info.java for the application that requires all third-party libraries as automatic modules.
B.Place all third-party JARs on the classpath and the application JARs on the module path.
C.Place all JARs on the module path and use the --add-reads and --add-exports flags to resolve dependencies.
D.Use the jlink tool to create a custom runtime image that includes all needed modules.
AnswerA

Automatic modules allow backward compatibility; the application can declare requires on the library names derived from JAR names.

Why this answer

Option B is correct because creating a module-info.java that requires the third-party libraries as automatic modules (by placing them on the module path) allows the application to be modular while using libraries without module-info. Option A is wrong because mixing classpath and module path can lead to class-loading inconsistencies and is not recommended. Option C is wrong because using --add-reads and --add-exports for all libraries is verbose and error-prone.

Option D is wrong because jlink creates a runtime image but does not solve the modularization of dependencies.

Practice this question →
6
Multi-Selecthard

Which TWO are valid uses of the 'jmod' tool in Java 17?

Select 2 answers
A.Creating a custom runtime image.
B.Listing the contents of a JMOD file.
C.Creating a JMOD file from a modular jar and native libraries.
D.Executing a JMOD file as an application.
E.Identifying module dependencies of a jar.
AnswersB, C

jmod list command lists contents of a JMOD file.

Why this answer

The 'jmod' tool is primarily used for creating and inspecting JMOD files, which are a packaging format for Java modules that can include native libraries, configuration files, and other resources beyond what a modular JAR can hold. Option B is correct because 'jmod list' lists the contents of a JMOD file, showing its entries such as classes, native code, and legal notices. Option C is correct because 'jmod create' can create a JMOD file from a modular JAR and additional native libraries using the --libs option.

Exam trap

The trap here is confusing the roles of 'jmod' (packaging) with 'jlink' (runtime image creation) and 'jdeps' (dependency analysis), leading candidates to incorrectly assign runtime image creation or dependency analysis to 'jmod'.

Practice this question →
7
MCQhard

A company runs a Java 17 microservice that reads stock market data from a WebSocket and processes it. The application is packaged as an executable JAR using Maven Shade Plugin. Recently, after a dependency update, the application started throwing 'javax.net.ssl.SSLHandshakeException: PKIX path building failed' when connecting to the WebSocket. The security team insists that no certificates should be imported into the default truststore. The application already includes a custom truststore file 'certs.jks' in the resources folder. The developer had been loading it programmatically but the new dependency uses a different SSL context. The application must trust the WebSocket server without modifying JVM defaults. Which action should be taken?

A.Set the system property 'javax.net.ssl.trustStore' to the path of 'certs.jks' and 'javax.net.ssl.trustStorePassword' to its password.
B.Add the certificate to the default truststore using keytool and restart the application.
C.Use the jlink tool to create a custom runtime image that includes the certificate.
D.Create a custom TrustManager that bypasses all certificate validation.
AnswerA

This tells the JVM to use the custom truststore globally.

Why this answer

Option A is correct because setting the system properties 'javax.net.ssl.trustStore' and 'javax.net.ssl.trustStorePassword' overrides the default JVM truststore globally for all SSL contexts within the application. This allows the custom 'certs.jks' file to be used without modifying the JVM's default truststore, satisfying the security team's requirement. The new dependency causing the issue likely uses the default SSL context, which will now pick up the custom truststore via these system properties.

Exam trap

The trap here is that candidates may think the system properties only affect the default SSLContext, but in practice, many libraries rely on the default SSLContext, making this a global and effective solution without modifying JVM defaults.

How to eliminate wrong answers

Option B is wrong because it directly violates the security team's explicit requirement that no certificates should be imported into the default truststore. Option C is wrong because jlink creates a custom runtime image by linking modules, but it does not provide a mechanism to inject or include a custom truststore file into the SSL context; it is used for module reduction, not for truststore configuration. Option D is wrong because creating a custom TrustManager that bypasses all certificate validation would disable SSL certificate verification entirely, creating a severe security vulnerability and violating the principle of trusting only the specific WebSocket server.

Practice this question →
8
MCQhard

Refer to the exhibit. The resulting image directory includes a 'bin' directory with java launcher. When running the application, a NoClassDefFoundError occurs for a class from module com.example.lib. What is the most likely cause?

A.The --compress=2 option altered the class.
B.The application uses reflection to access the class.
C.The com.example.lib module was not added via --add-modules.
D.The --strip-debug option removed the class file.
AnswerC

Only modules explicitly added (and their transitive dependencies) are included.

Why this answer

When using jlink to create a custom runtime image, only the modules explicitly specified (or their transitive dependencies) are included. If the application depends on com.example.lib but it was not added via --add-modules, the module's classes will be missing from the image, causing a NoClassDefFoundError at runtime. This is the most direct cause among the options.

Exam trap

Oracle often tests the distinction between missing classes due to module omission (NoClassDefFoundError) versus missing classes due to reflection (ClassNotFoundException), and candidates may confuse --strip-debug with removing class files.

How to eliminate wrong answers

Option A is wrong because --compress=2 applies ZIP compression to resources in the image, not to class files, and does not alter class bytecode or cause classes to be missing. Option B is wrong because reflection does not cause NoClassDefFoundError; it may cause ClassNotFoundException if the class is absent, but the error here is specifically about a class that was expected to be present but is not, which is a module resolution issue. Option D is wrong because --strip-debug removes debugging information (like line numbers and local variable names) from class files, not the class files themselves, so the class remains available for loading.

Practice this question →
9
MCQhard

Given the output of `java --list-modules` from a Java 17 installation, which module is NOT included by default when using the `--release 17` flag with `javac`?

A.jdk.jfr
B.jdk.incubator.foreign
C.java.net.http
D.java.sql
AnswerB

Correct: Incubator modules are not included when using --release.

Why this answer

The `--release 17` flag restricts `javac` to the standard Java SE 17 API, which does not include incubator modules like `jdk.incubator.foreign`. Incubator modules are preview features that are not part of the Java SE specification and must be explicitly added with `--add-modules`.

Exam trap

Oracle often tests the distinction between standard modules (always included with `--release`) and incubator/preview modules (explicitly opt-in), causing candidates to assume all listed modules are part of the default API.

How to eliminate wrong answers

Option A is wrong because `jdk.jfr` (Java Flight Recorder) is a standard JDK module included in Java SE 17 and is part of the default API when using `--release 17`. Option C is wrong because `java.net.http` (HTTP Client) is a standard module introduced in Java 11 and is included in the Java SE 17 API. Option D is wrong because `java.sql` (JDBC API) is a core Java SE module that has been part of the standard API since Java 8 and is included by default with `--release 17`.

Practice this question →
10
MCQeasy

A development team is working on a Java 17 application that must be packaged as a custom runtime image for deployment on a Linux server without a JDK installed. The application uses `java.base`, `java.logging`, and `java.sql` modules, and also requires the `jdk.crypto.cryptoki` module for hardware security module (HSM) integration. The team wants to minimize the image size while ensuring all necessary modules are included. They run `jlink --add-modules java.base,java.logging,java.sql,jdk.crypto.cryptoki --output myapp-runtime`. The resulting image runs the application but fails at startup with a `ClassNotFoundException` for `javax.crypto.spec.SecretKeySpec`. Which action should the team take to resolve the issue?

A.Manually add the `java.security.jgss` module to the `--add-modules` list.
B.Use the `--list-modules` option with jlink to verify which modules are included, then add any missing ones.
C.Add `ALL-MODULE-PATH` to the `--add-modules` list to include all available modules.
D.Add `--bind-services` to the jlink command to include service provider modules.
AnswerD

Correct: --bind-services links service provider modules required by the specified modules, which may include necessary crypto implementations.

Why this answer

The `jdk.crypto.cryptoki` module is a service provider module that provides cryptographic services via the Java Cryptography Architecture (JCA). When using `jlink`, service provider modules are not automatically included unless `--bind-services` is specified, because `jlink` only includes modules directly referenced in the module graph. The `javax.crypto.spec.SecretKeySpec` class is part of `java.base`, but the actual provider implementation that makes it available at runtime is in `jdk.crypto.cryptoki`; without `--bind-services`, the service linkage is missing, causing the `ClassNotFoundException`.

Exam trap

The trap here is that candidates assume adding the module name to `--add-modules` is sufficient, but they overlook that `jlink` requires `--bind-services` to include service provider modules that are discovered via the service loader mechanism.

How to eliminate wrong answers

Option A is wrong because `java.security.jgss` is unrelated to the missing `javax.crypto.spec.SecretKeySpec`; that class is in `java.base`, and the issue is about service provider resolution, not a missing module dependency. Option B is wrong because `--list-modules` only shows which modules are currently included; it does not fix the missing service provider linkage, and the team already knows the module is included. Option C is wrong because `ALL-MODULE-PATH` would include every module on the module path, defeating the purpose of minimizing image size and potentially including unnecessary modules; it also does not address the service binding issue.

Practice this question →
11
MCQmedium

A team is migrating a large monolithic Java 8 application to Java 17 using modules. They want to ensure that only the required packages are exported. Which tool should they use to analyze current dependencies and generate module descriptors?

A.jlink
B.javap
C.jar
D.jdeps
AnswerD

jdeps analyzes dependencies and can generate module-info.java suggestions.

Why this answer

jdeps is the correct tool because it is specifically designed to analyze class dependencies in Java applications and can generate module descriptor (module-info.java) suggestions. It shows which packages are used and which are not, enabling the team to export only the required packages when migrating to Java modules.

Exam trap

The trap here is that candidates confuse jdeps with jlink or jar, thinking that any packaging tool can analyze dependencies, but only jdeps provides the specific module descriptor generation capability required for modularization.

How to eliminate wrong answers

Option A is wrong because jlink is a tool for creating custom runtime images by assembling modules and their dependencies, not for analyzing dependencies or generating module descriptors. Option B is wrong because javap is a disassembler that shows class file details like methods and fields, but it does not analyze package-level dependencies or produce module-info files. Option C is wrong because jar is used to create, view, and extract JAR files, not to analyze dependencies or generate module descriptors.

Practice this question →
12
MCQeasy

A developer needs to compile and execute a Java application on a server. Which of the following environments is sufficient to perform both tasks?

A.Both JDK and JRE
B.JDK only
C.Neither JDK nor JRE
D.JRE only
AnswerB

JDK contains javac and java, enabling both compilation and execution.

Why this answer

Option A is correct because the JDK includes both the compiler (javac) and the runtime (java). Option B is wrong because the JRE provides only the runtime, not the compiler. Option C is wrong because having both is redundant; the JDK alone is sufficient.

Option D is wrong because it is essentially the same as option A but more specific; however, the JDK is the standard term and is sufficient.

Practice this question →
13
MCQeasy

A Java developer is building a modular application that uses only the `java.base` and `java.sql` modules. The application runs correctly with a full JDK 17 installation. The developer wants to distribute a minimal runtime image to reduce download size for end users. They have the application module JAR file and all dependencies are modular. The developer runs the command `jlink --module-path $JAVA_HOME/jmods:app --add-modules app --output myimage` but receives an error: "Error: java.sql module not found". What is the most likely cause of this error?

A.The `--add-modules` option can only be used with root modules, but `java.sql` is not a root module.
B.The `java.sql` module is not a standard JDK module and must be compiled separately.
C.The module path is missing the application's output directory.
D.The `--add-modules` option was not specified for `java.sql`, so it is not included in the runtime image.
AnswerD

jlink only includes modules explicitly listed with `--add-modules` and their transitive dependencies. Since `java.sql` is not added, it is missing.

Why this answer

Option D is correct because `jlink` only includes modules explicitly specified with `--add-modules` (plus their transitive dependencies) in the runtime image. The command only specifies `--add-modules app`, so `java.sql` is not included unless `app` requires it. Since the error says 'java.sql module not found', the most likely cause is that `java.sql` was not listed in `--add-modules` and is not a transitive dependency of `app`.

Exam trap

The trap here is that candidates assume `jlink` automatically includes all JDK modules present in the module path, but it only includes those explicitly requested or required by the specified root modules.

How to eliminate wrong answers

Option A is wrong because `--add-modules` can specify any module, not just root modules; the concept of 'root modules' is irrelevant here. Option B is wrong because `java.sql` is a standard JDK module included in the `java.sql` jmod file within `$JAVA_HOME/jmods`. Option C is wrong because the module path includes `$JAVA_HOME/jmods:app`, which covers both JDK modules and the application module; the error is about `java.sql`, not the application's output directory.

Practice this question →
14
MCQmedium

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?

A.Add a module-info.class file to the jar using jar tool.
B.Place the jar on the module path; it becomes an automatic module.
C.Place the jar on the classpath; it becomes an unnamed module.
D.Use jmod tool to convert the jar into a JMOD file.
AnswerB

Automatic modules are derived from jar files on the module path that lack module-info.class.

Why this answer

Option B is correct because 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.

Exam trap

The trap here is that candidates 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.

How to eliminate wrong answers

Option A is wrong because adding a module-info.class to a JAR that was not designed for the module system would require explicit module declarations and may break encapsulation or cause illegal access errors; the jar tool can add files but does not automatically generate a correct module descriptor. Option C is wrong because placing the JAR on the classpath makes it part of the unnamed module, which cannot be referenced by named modules via 'requires' and thus does not improve encapsulation as intended. Option D is wrong because the jmod tool is used to create JMOD files for platform modules or custom modules, not to convert a plain JAR into a module; JMOD files are not typically used for third-party libraries and do not solve the missing module-info issue.

Practice this question →
15
MCQeasy

A developer has a module named 'com.example.app' that exports a package 'com.example.api'. Another module 'com.example.client' requires 'com.example.app'. Which directive must be in the module-info.java of 'com.example.client'?

A.opens com.example.app;
B.uses com.example.api;
C.exports com.example.api;
D.requires com.example.app;
AnswerD

This correctly declares the dependency.

Why this answer

Option D is correct because the 'requires' directive in a module-info.java file declares a dependency on another module. For 'com.example.client' to access the exported packages of 'com.example.app', it must include 'requires com.example.app;'. This is the standard mechanism for module dependency in the Java Platform Module System (JPMS).

Exam trap

The trap here is that candidates may confuse 'requires' with 'exports' or 'opens', mistakenly thinking that the client module must export or open the server module's package, rather than simply declaring a dependency.

How to eliminate wrong answers

Option A is wrong because 'opens com.example.app;' is used to allow deep reflection on a module's packages at runtime, not to declare a compile-time dependency; it does not grant access to exported types. Option B is wrong because 'uses com.example.api;' declares a service dependency for the ServiceLoader mechanism, not a module dependency; it requires the module to already be 'requires'ed. Option C is wrong because 'exports com.example.api;' is a directive for the module that owns the package to make it accessible to other modules; 'com.example.client' cannot export a package it does not own.

Practice this question →
16
MCQeasy

A developer runs 'java --list-modules' and sees the output above. Which command can be used to create a custom runtime image containing only the 'java.base' module?

A.jar --create --file myimage --module java.base
B.jimage --add-modules java.base --output myimage
C.jlink --modules java.base --output myimage
D.jlink --add-modules java.base --output myimage
AnswerD

Correct syntax for jlink.

Why this answer

The `jlink` tool is used to assemble and optimize a set of modules and their dependencies into a custom runtime image. The `--add-modules` option specifies which modules to include, and `--output` specifies the target directory. Option D correctly uses `jlink --add-modules java.base --output myimage` to create a runtime image containing only the `java.base` module.

Exam trap

The trap here is confusing `jlink` with `jimage` or `jar`, and mistaking `--modules` for the correct `--add-modules` option, which is a common syntax error that candidates make when they recall the general concept but not the exact command flags.

How to eliminate wrong answers

Option A is wrong because `jar --create --file` is used to create a JAR archive, not a runtime image; it cannot produce a JRE image. Option B is wrong because `jimage` is a tool for listing or extracting contents of a jimage file, not for creating a runtime image; it does not have `--add-modules` or `--output` options for image creation. Option C is wrong because `jlink` does not accept `--modules`; the correct option is `--add-modules` to specify which modules to include in the image.

Practice this question →
17
MCQeasy

Refer to the exhibit. The module path is correctly set to include the JAR containing the module. What is the most likely issue?

A.The Main class is not specified as the main class in the module descriptor or manifest.
B.The JAR does not have a module-info.class.
C.The module requires a module that is not on the module path.
D.The Main class is not in an exported package.
AnswerA

The JVM needs the main class specified via --main-class or manifest.

Why this answer

When launching a modular JAR with `java -jar`, the JVM requires the main class to be explicitly declared either in the module descriptor (`module-info.java` with a `main-class` directive) or in the JAR's `MANIFEST.MF` (`Main-Class` attribute). Without this declaration, the JVM cannot determine the entry point, resulting in a 'Main class not found' error. Option A correctly identifies this missing declaration as the most likely issue.

Exam trap

Oracle often tests the distinction between module-path requirements for `java -jar` versus `java --module`, where candidates mistakenly think the main class must be exported or that a missing `module-info.class` is the issue, but the real trap is the missing main-class declaration in either the module descriptor or manifest.

How to eliminate wrong answers

Option B is wrong because a modular JAR must contain a `module-info.class` to be recognized as a module; if it were missing, the JVM would treat the JAR as a named module on the module path, but the question states the module path is correctly set, implying the JAR is valid. Option C is wrong because if a required module were missing, the JVM would throw a `java.lang.module.ResolutionException` at startup, not a 'Main class not found' error. Option D is wrong because the main class does not need to be in an exported package when launched with `java -jar`; the module system grants access to the main class internally, and export is only needed for reflection or cross-module access.

Practice this question →
18
MCQeasy

Which command creates a custom runtime image containing only the modules needed by an application, reducing the size of the JRE?

A.jmod
B.jar
C.jlink
D.jdeps
AnswerC

jlink links modules and creates a custom runtime image.

Why this answer

The `jlink` tool is specifically designed to create a custom runtime image that contains only the modules required by a given application, along with their transitive dependencies. This reduces the JRE size by eliminating unused modules, which is a key feature of Java's module system (Project Jigsaw). Option C is correct because `jlink` is the only command among the choices that performs this modular runtime image assembly.

Exam trap

The trap here is that candidates confuse `jlink` with `jmod` or `jar`, assuming any packaging tool can reduce the JRE, but only `jlink` performs module-aware linking to create a minimal runtime image.

How to eliminate wrong answers

Option A is wrong because `jmod` is used to create, list, and inspect JMOD files (a format for packaging modules with native code and configuration), not to create a runtime image. Option B is wrong because `jar` packages class files and resources into a JAR archive, but it does not resolve module dependencies or produce a reduced JRE. Option D is wrong because `jdeps` analyzes class dependencies and module requirements, but it only outputs dependency information and does not generate a runtime image.

Practice this question →
19
Multi-Selecthard

Which THREE are valid Java commands for launching a modular application?

Select 3 answers
A.java -p mods -m com.app
B.java --class-path classes --module-path mods --module com.app
C.java -p classes -m com.app
D.java --module-path mods --module com.app/com.app.Main
E.java -p mods --add-modules com.app -m com.app
AnswersA, B, D

Short form: -p for module path, -m for module.

Why this answer

Options A, C, and D are correct. Option A: correct syntax for module path and main module. Option B: invalid because --add-modules cannot specify a module with a main class; -m is used.

Option C: valid with single module path. Option D: valid with classpath and module path. Option E: invalid because -p is for module path, not classpath.

Practice this question →
20
Multi-Selectmedium

Which TWO statements about the Java Platform Module System (JPMS) are true? (Choose two.)

Select 2 answers
A.All classes on the classpath are automatically placed in the boot layer.
B.JPMS provides reliable configuration through explicit module dependencies.
C.A module declaration is placed in a file named module-info.class.
D.JPMS allows the use of the classpath to add modules to the module graph.
E.JPMS supports strong encapsulation by controlling which packages are accessible to other modules.
AnswersB, E

Correct: JPMS requires modules to declare dependencies explicitly, eliminating classpath issues.

Why this answer

Option B is correct because JPMS enforces reliable configuration by requiring modules to explicitly declare their dependencies using the 'requires' directive in the module descriptor. This eliminates the classpath's silent dependency resolution, where missing or conflicting JARs often cause runtime errors like ClassNotFoundException.

Exam trap

The trap here is confusing the unnamed module (classpath) with the boot layer, or assuming that module-info.class is the source file rather than the compiled output, leading candidates to incorrectly select A or C.

Practice this question →
21
MCQmedium

You are a Java developer at a logistics company. Your team is maintaining a legacy Java 8 application that uses dozens of jars on the classpath. The company has decided to migrate to Java 17 and adopt the module system. As a first step, you are analyzing the application's dependencies using jdeps. You run 'jdeps -s -dotoutput /tmp/deps' on all jars. The output shows many dependencies labeled 'not found' for internal packages that belong to other jars in the application. The packages are correctly exported by the respective jars (which are on the classpath). You suspect that because the jars are on the classpath, jdeps cannot resolve inter-jar dependencies as modules. To get accurate dependency information, what should you do?

A.Use jlink to create a custom runtime image that includes all the jars.
B.Place all the jars on the module path and remove them from the classpath when running jdeps.
C.Run jdeps with the --module-path option pointing to the directory containing all jars, and keep the jars on the classpath.
D.Convert each jar into a named module by adding module-info.java to each jar and recompiling.
AnswerB

This makes them automatic modules, allowing jdeps to resolve inter-jar dependencies as module dependencies.

Why this answer

When jars are on the classpath, jdeps treats them as unnamed modules and cannot resolve inter-jar dependencies as module-level relationships, leading to 'not found' labels. Placing all jars on the module path (Option B) forces jdeps to treat each jar as a module (if it has a module-info.class) or as an automatic module (if it does not), enabling accurate dependency resolution. This is the correct approach because the module path is designed for module-aware analysis, while the classpath is a legacy flat namespace.

Exam trap

The trap here is that candidates think the --module-path option can be used while keeping jars on the classpath, but jdeps only performs module-aware analysis when all relevant jars are on the module path and none are on the classpath.

How to eliminate wrong answers

Option A is wrong because jlink creates a custom runtime image by linking modules, but it does not analyze dependencies; it is a deployment tool, not an analysis tool. Option C is wrong because jdeps ignores the --module-path option when jars remain on the classpath; the classpath takes precedence and jars are still treated as unnamed modules, so the 'not found' issue persists. Option D is wrong because converting jars to named modules by adding module-info.java is unnecessary for analysis; jdeps can treat jars as automatic modules on the module path without modifying them, and recompiling is a later migration step, not a prerequisite for accurate jdeps output.

Practice this question →
22
Multi-Selecthard

Which two statements are true about Java module declarations? (Choose two.)

Select 2 answers
A.The uses directive is used to specify that a module provides a service implementation.
B.A module can read another module only if it explicitly requires it.
C.A qualified export allows access to the exported package only to specific modules.
D.The requires directive can be used to specify a module that is optional.
E.The opens directive allows reflective access to all types and members in the opened package, including private members.
AnswersC, E

Qualified exports restrict accessibility to a comma-separated list of module names.

Why this answer

Options A and B are correct. A qualified export (exports package to module) restricts access to specified modules. The opens directive grants reflective access to all members, including private ones.

Option C is false because java.base is implicitly required; in a named module, other modules must be explicitly required or inherited. Option D is false: uses is for consuming services, provides is for implementing them. Option E is false: requires static makes a dependency optional, not requires alone.

Practice this question →
23
MCQhard

A company uses jlink to create a custom runtime image. They want to reduce the image size by removing debug information. Which jlink option or plugin should they use?

A.--compress=2
B.--strip-debug
C.--no-header-files
D.--bind-services
AnswerB

Specifically removes debug information to reduce image size.

Why this answer

The `--strip-debug` option in jlink removes debug information from the custom runtime image, including line numbers, local variable tables, and source file references, which significantly reduces the image size. This is the correct option for stripping debug information, as it directly targets the removal of debugging metadata from the generated image.

Exam trap

The trap here is that candidates often confuse `--strip-debug` with `--compress=2`, assuming compression removes debug information, but compression only reduces file size without eliminating the underlying debug metadata.

How to eliminate wrong answers

Option A is wrong because `--compress=2` applies ZIP compression to resources in the runtime image, which reduces size through compression but does not remove debug information. Option C is wrong because `--no-header-files` excludes header files (e.g., C headers for native code) from the image, which is unrelated to debug information removal. Option D is wrong because `--bind-services` enables service binding resolution for modules, which affects module graph resolution but has no impact on debug information.

Practice this question →
24
MCQhard

A team is developing a large enterprise application using Java 17. The application consists of multiple modules: core (provides logging and configuration), services (business logic), and web (REST endpoints). The modules are packaged as separate JAR files and deployed on a server. During runtime, the web module throws a java.lang.ClassNotFoundException for a class that is part of the core module. The core module's module-info.java exports the package containing the missing class. The web module's module-info.java requires core. However, the services module also needs the same class but uses a different version of it, causing conflicts. The team decides to use the class path for the conflicting package and the module path for the rest. They add the conflicting JAR to the class path and keep the other JARs on the module path. After this change, the web module still cannot find the class, but the services module works fine. What is the most likely cause of the issue?

A.The services module is using an automatic module, which automatically reads the unnamed module, while the web module is a named module that does not.
B.The class path is not scanned for JAR files unless the module path is empty.
C.The web module is a named module and cannot access classes from a split package that is also in the unnamed module.
D.The core module's module-info.java does not export the package to the web module; it only exports it to all modules.
AnswerC

The module system prevents named modules from accessing split packages from the class path to maintain reliable configuration.

Why this answer

Option C is correct because when a named module (the web module) is on the module path, it cannot access classes from the unnamed module (the class path) if those classes belong to a package that is also exported by another named module on the module path. This creates a split package, which is forbidden by the Java module system. The core module exports the package, so the web module cannot load the class from the class path JAR, resulting in ClassNotFoundException.

Exam trap

The trap here is that candidates often think the issue is about module visibility (exports) or class path scanning order, but the real constraint is the split package rule, which prevents a named module from accessing a package that is already defined by another named module on the module path.

How to eliminate wrong answers

Option A is wrong because the services module is not necessarily an automatic module; the scenario states it uses a different version of the class from the class path, and automatic modules can read the unnamed module, but the core issue is about split packages, not automatic module behavior. Option B is wrong because the class path is scanned for JAR files even when the module path is non-empty; the unnamed module is always present and accessible to named modules only for packages not exported by any named module. Option D is wrong because the core module's module-info.java exports the package to all modules (implied by 'exports' without a 'to' clause), so it does export to the web module; the problem is the split package, not insufficient exports.

Practice this question →
25
MCQeasy

A developer creates a Java application that uses the new 'jpackage' tool to create an installer for Windows. The application is modular and has a main class declared in module-info. Which option is required to specify the main class when using jpackage?

A.-classpath
B.--module-path
C.--main-jar
D.--module
AnswerD

For modular applications, jpackage uses --module to specify the main module, and the application's main class is derived from the module descriptor.

Why this answer

For a modular application with a main class declared in module-info, jpackage requires the `--module` option to specify the module name and, optionally, the main class (e.g., `--module com.example/com.example.Main`). This is because jpackage uses the module system to resolve the entry point, not a classpath or JAR-based approach.

Exam trap

The trap here is that candidates confuse `--module` with `--module-path` or `--main-jar`, mistakenly thinking the main class must be specified via a JAR or classpath even when the module system already declares it.

How to eliminate wrong answers

Option A is wrong because `-classpath` is a legacy option for specifying class paths in non-modular applications, and jpackage does not support it for modular applications. Option B is wrong because `--module-path` is used to specify the location of module directories or JARs, not to declare the main class. Option C is wrong because `--main-jar` is used for non-modular applications packaged as JARs, not for modular applications where the main class is defined in module-info.

Practice this question →
26
MCQmedium

A developer creates a module `com.example.app` that requires `java.sql` and `com.example.util`. The module is compiled and packaged into a JAR. When launching the application with `java --module-path app.jar:lib --module com.example.app`, it fails with `java.lang.module.ResolutionException: Module com.example.util not found`. What is the most likely cause?

A.The module `com.example.util` is an automatic module and requires specific flags.
B.The module `com.example.util` is not in the module path.
C.The module `com.example.util` is a named module but not exported.
D.The module `com.example.util` is on the classpath and not visible to module system.
AnswerB

The module path must include all required modules explicitly.

Why this answer

The error `Module com.example.util not found` indicates that the module system cannot locate `com.example.util` on the module path. Since the command specifies `--module-path app.jar:lib`, the JAR for `com.example.util` must be present in the `lib` directory (or another directory on that path). If it is missing or not in the correct location, the module resolution fails.

Option B correctly identifies that the module is simply not on the module path.

Exam trap

Oracle often tests the distinction between module resolution failures (missing module) and access control failures (module found but not exported), so candidates may incorrectly choose an option about exports or classpath visibility when the actual issue is that the module JAR is simply not present on the module path.

How to eliminate wrong answers

Option A is wrong because automatic modules do not require special flags to be found; they are resolved automatically when placed on the module path. Option C is wrong because a named module that is not exported would cause an `IllegalAccessError` at runtime, not a `ResolutionException` at startup. Option D is wrong because placing a module on the classpath makes it invisible to the module system for `requires` directives; the module system only resolves modules from the module path, not the classpath.

Practice this question →
27
MCQeasy

A Java application packaged as a JAR file with a manifest containing `Main-Class: com.example.Main` is correctly run using `java -jar app.jar`. However, when run with `java -cp app.jar com.example.Main`, it throws a `NoClassDefFoundError` for a class `com.example.helper.Util`. What is the most likely cause?

A.The Util class is missing from the JAR.
B.The JAR's manifest Class-Path entry is not being honored when using -cp.
C.The -jar option automatically adds the JAR's dependencies to the classpath.
D.The main class name is misspelled.
AnswerB

When using -cp, the Class-Path from manifest is ignored; you must explicitly include dependencies.

Why this answer

When using `java -jar`, the JVM reads the manifest's `Class-Path` entry to locate dependencies. However, when using `-cp` (or `-classpath`), the manifest's `Class-Path` is ignored; the classpath is determined solely by the `-cp` argument. Since `com.example.helper.Util` is not on the explicit classpath, a `NoClassDefFoundError` occurs.

This is a fundamental difference in how the JVM resolves classpaths between the two launch modes.

Exam trap

Oracle often tests the misconception that the manifest's `Class-Path` is always honored regardless of how the JAR is launched, when in fact `-cp` completely overrides it.

How to eliminate wrong answers

Option A is wrong because if the Util class were missing from the JAR, the error would occur with both `-jar` and `-cp`; the fact that `-jar` works proves the class is present. Option C is wrong because `-jar` does not automatically add dependencies to the classpath; it only uses the manifest's `Class-Path` entries, which are not transitive or automatic. Option D is wrong because a misspelled main class would cause a `NoClassDefFoundError` for the main class itself, not for a helper class, and the question states the main class is correctly specified.

Practice this question →
28
MCQmedium

Given two named modules where module com.example.app requires module com.example.lib, which packages of com.example.lib are readable by com.example.app?

A.All packages except those explicitly concealed
B.All packages of com.example.lib
C.Only the packages opened by com.example.lib
D.Only the packages exported by com.example.lib
AnswerD

A module reads only exported packages of required modules.

Why this answer

Option D is correct because in the Java module system, a module can only access packages from another module that are explicitly exported using the `exports` directive in the module's `module-info.java` file. Since `com.example.app` requires `com.example.lib`, only the packages exported by `com.example.lib` are readable; unexported packages remain encapsulated and inaccessible.

Exam trap

The trap here is that candidates confuse `opens` with `exports`, thinking that opening a package for reflection also makes it readable, but `opens` only grants reflective access and does not allow compile-time or direct read access.

How to eliminate wrong answers

Option A is wrong because the Java module system does not have a concept of 'concealed' packages; instead, packages are either exported or not, and all non-exported packages are implicitly encapsulated. Option B is wrong because requiring a module does not grant access to all its packages; only those explicitly exported are readable. Option C is wrong because 'opened' packages (via the `opens` directive) are for deep reflection at runtime, not for compile-time or read access; readability requires `exports`, not `opens`.

Practice this question →
29
MCQhard

Given the module descriptor and invocation, what will happen?

A.The application runs successfully because com.example.store is added with --add-modules, and its exported packages are available.
B.The application throws NoClassDefFoundError because the Main class is in a different module.
C.The application runs successfully because com.example.store is on the module path.
D.The application throws ModuleNotFoundException because com.example.store is not required by com.example.payment.
AnswerA

--add-modules makes com.example.store available to other modules, including the main module.

Why this answer

Option A is correct because the `--add-modules com.example.store` directive explicitly adds the module `com.example.store` to the set of root modules at startup, making its exported packages available to the unnamed module (or to modules that do not otherwise require it). Since the `Main` class is in the unnamed module (not in a named module), it can access the exported packages of `com.example.store` without a `requires` clause. This is the intended behavior of `--add-modules` for resolving modules that are not automatically resolved.

Exam trap

The trap here is that candidates often assume that simply placing a module on the module path makes it automatically accessible to the unnamed module, but the module system requires explicit opt-in via `--add-modules` for modules not required by a named module.

How to eliminate wrong answers

Option B is wrong because `NoClassDefFoundError` would occur only if a class was present at compile time but missing at runtime; here, the module is explicitly added via `--add-modules`, so the classes are available. Option C is wrong because simply being on the module path does not automatically resolve a module for the unnamed module; the module must be explicitly added with `--add-modules` or be a root module (e.g., via `requires` in a named module). Option D is wrong because `ModuleNotFoundException` is thrown only when a module cannot be found on the module path or when `--add-modules` specifies a non-existent module; here, `com.example.store` exists on the module path and is explicitly added, so no exception occurs.

Practice this question →
30
MCQhard

A company uses a multi-release JAR (MR-JAR) that contains classes for Java 9 and Java 11 in `META-INF/versions/9/` and `META-INF/versions/11/` respectively. The application runs on Java 17. Which version of a class that exists in both versioned directories is loaded?

A.The version from META-INF/versions/9/
B.The version from the root of the JAR
C.The version from META-INF/versions/11/
D.The version from META-INF/versions/17/
AnswerC

Java 17 selects the highest version ≤ 17, which is 11 if present.

Why this answer

Option C is correct because in a multi-release JAR (MR-JAR), the Java runtime selects the versioned directory that matches the major version of the running Java platform, or the highest versioned directory that does not exceed that version. Since the application runs on Java 17, and the highest available versioned directory is for Java 11 (META-INF/versions/11/), the class from that directory is loaded. The root directory is used only when no appropriate versioned directory exists.

Exam trap

The trap here is that candidates assume the runtime will load the version matching the exact running Java version (Java 17) or fall back to the root, but the MR-JAR specification actually selects the highest versioned directory that does not exceed the current version, not the exact match or the root.

How to eliminate wrong answers

Option A is wrong because the runtime does not select the lowest versioned directory; it selects the highest versioned directory that is less than or equal to the current major version (Java 17), so Java 9 would be ignored in favor of Java 11. Option B is wrong because the root directory is only used as a fallback when no versioned directory matches the current Java version; here, versioned directories for Java 9 and 11 exist, so the root is not consulted for this class. Option D is wrong because there is no META-INF/versions/17/ directory in the JAR; the runtime cannot load a version that does not exist, and it does not synthesize or default to a non-existent version.

Practice this question →
31
Multi-Selecteasy

Which TWO statements are true about the Java Platform Module System (JPMS) introduced in Java 9?

Select 2 answers
A.The module path is searched after the class path when resolving types.
B.The module declaration is stored in a file named module-info.java.
C.A module must explicitly export a package to make it accessible to other modules.
D.An automatic module is one that has a module-info.class file at its root.
E.A named module can access the unnamed module without any explicit declaration.
AnswersB, C

The module declaration is placed in module-info.java, which is compiled to module-info.class.

Why this answer

Option B is correct because the module declaration in JPMS is indeed stored in a file named module-info.java, which is compiled into module-info.class and placed at the root of the module. This file defines the module's name, dependencies (requires), and exported packages (exports).

Exam trap

The trap here is that candidates often confuse the search order of module path vs. class path (A) or mistakenly think automatic modules have a module-info.class (D), when in fact they are automatically derived from JARs without one.

Practice this question →
32
MCQmedium

A developer runs the command above on a JAR file. Which statement accurately describes the module myapp?

A.The module opens com.myapp.internal for deep reflection to all modules.
B.The module provides a service implementation.
C.The module exports com.myapp.internal to the module myapp.tests only.
D.The module requires java.base explicitly; it is not mandated.
AnswerC

The qualified exports directive restricts access to the specified module.

Why this answer

Option C is correct because the command `java --describe-module myapp` outputs the module descriptor, which includes `exports com.myapp.internal to myapp.tests`. This indicates that the module `myapp` exports the package `com.myapp.internal` specifically to the module `myapp.tests` only, not to all modules. The `exports ... to` syntax restricts access to a qualified list of modules.

Exam trap

Oracle often tests the distinction between `exports` (compile-time access) and `opens` (reflective access), and the trap here is that candidates confuse a qualified export with an `opens` directive, or assume `exports` without a qualifier means all modules, when the `to` clause specifies a limited set.

How to eliminate wrong answers

Option A is wrong because `opens` is used for deep reflection (allowing reflective access to private members), but the command output shows `exports`, not `opens`. Option B is wrong because a service implementation is declared with `provides ... with ...` in the module descriptor, which is not indicated by the `exports` statement. Option D is wrong because `java.base` is always implicitly required by all modules; it does not need to be explicitly listed in the module descriptor, and the command output would not show it unless explicitly declared.

Practice this question →
33
Multi-Selectmedium

Which TWO statements are true about the Java module system (JPMS) as of Java 17?

Select 2 answers
A.A named module is defined by a module-info.class file placed in the root of the module.
B.An automatic module can contain a module-info.class file.
C.A jar file placed on the classpath that lacks module-info.class becomes an automatic module.
D.A named module can read an unnamed module by default.
E.An unnamed module is created when code is placed on the classpath.
AnswersA, E

Named modules have a module descriptor (module-info.java compiled to module-info.class).

Why this answer

Option A is correct because a named module in JPMS is defined by a module-info.class file (compiled from module-info.java) placed in the root directory of the module. This file declares the module's name, dependencies, and exported packages, making it a fundamental requirement for a named module.

Exam trap

The trap here is confusing the classpath with the module path; candidates often think JARs on the classpath become automatic modules, but automatic modules only arise from JARs on the module path that lack a module-info.class.

Practice this question →
34
MCQmedium

A company wants to distribute a Java desktop application with a bundled JRE for end users who may not have Java installed. Which tool should they use?

A.jpackage
B.jlink
C.jar
D.jmod
AnswerA

jpackage creates native installers with bundled JRE.

Why this answer

jpackage is the correct tool because it is specifically designed to package a Java application along with a bundled JRE into a native installer (e.g., .exe, .dmg, .deb) for distribution to end users who may not have Java installed. It uses the jlink tool internally to create a custom runtime image and then wraps it with platform-specific packaging tools, ensuring the application runs independently of any pre-installed JRE.

Exam trap

The trap here is that candidates often confuse jlink (which creates a custom runtime) with jpackage (which bundles the runtime with the application into a distributable installer), leading them to pick jlink because they know it can produce a standalone JRE.

How to eliminate wrong answers

Option B (jlink) is wrong because jlink creates a custom runtime image (a modular JRE) but does not produce a distributable installer or bundle the application with it; it is a building block used by jpackage, not a packaging tool itself. Option C (jar) is wrong because the jar tool only creates a JAR file (a compressed archive of class files and resources), which still requires a separate JRE to be installed on the target system to execute. Option D (jmod) is wrong because jmod is used to create JMOD files for modular libraries or applications, but these are not self-contained executables and cannot be directly run by end users without additional tooling.

Practice this question →
35
MCQeasy

A developer wants to create an executable JAR file. Which jar command option is used to specify the main class?

A.--main-class
B.--class-path
C.--module-version
D.--create
AnswerA

--main-class specifies the main class for an executable JAR.

Why this answer

Option A is correct because the `--main-class` option (or `-e` in older syntax) specifies the fully qualified name of the class containing the `public static void main(String[])` method when creating an executable JAR with the `jar` command. This entry is stored in the JAR's `META-INF/MANIFEST.MF` file under the `Main-Class` header, which the Java launcher reads to determine the entry point.

Exam trap

The trap here is that candidates often confuse `--main-class` with `--class-path` or think `--create` alone makes the JAR executable, but `--create` only builds the archive without setting an entry point.

How to eliminate wrong answers

Option B is wrong because `--class-path` sets the classpath for the JAR's dependencies, not the main class. Option C is wrong because `--module-version` specifies the version of a modular JAR, not the main class. Option D is wrong because `--create` (or `-c`) indicates the action to create a new JAR file, but it does not specify the main class; it must be combined with `--main-class` to make the JAR executable.

Practice this question →
36
MCQhard

A Java 17 application uses the Java Platform Module System (JPMS). The module 'com.example.service' exports 'com.example.service.api' and requires 'java.logging'. Another module 'com.example.client' requires 'com.example.service'. The client module cannot access the 'com.example.service.api' package. What is the most likely reason?

A.The 'com.example.service' module does not use 'requires transitive' for 'java.logging'.
B.The 'com.example.service.api' package is not exported by 'com.example.service'.
C.The 'com.example.client' module does not contain a 'requires com.example.service' directive.
D.The 'java.logging' module does not export its packages to 'com.example.service'.
AnswerC

A module must require the module that exports the packages it needs.

Why this answer

Option C is correct because the question states that the client module 'requires com.example.service', so the client module does contain the required directive. The most likely reason the client cannot access 'com.example.service.api' is that the 'com.example.service' module does not export that package. According to JPMS, a package must be explicitly exported via the 'exports' directive in the module-info.java of the owning module for other modules to access its public types.

Without that export, even with a 'requires' directive, the package remains inaccessible.

Exam trap

The trap here is that candidates may assume the 'requires' directive alone grants access to all packages of the required module, but JPMS requires explicit 'exports' for each package to be accessible, and the question's phrasing 'cannot access' often misleads into thinking the 'requires' directive is missing when it is actually present.

How to eliminate wrong answers

Option A is wrong because 'requires transitive' for 'java.logging' is unrelated to the client's access to 'com.example.service.api'; it only affects readability of transitive dependencies. Option B is wrong because the question explicitly states that 'com.example.service' exports 'com.example.service.api', so the package is exported. Option D is wrong because the 'java.logging' module's exports to 'com.example.service' are irrelevant to the client's access to 'com.example.service.api'; the issue is between the client and the service module, not between the service and java.logging.

Practice this question →
37
MCQmedium

Which statement is true about the result of executing the jlink command shown in the exhibit?

A.It compiles the com.example.app module before creating the image.
B.It creates a runtime image containing the com.example.app module and its resolved dependencies.
C.It creates a runtime image that includes only the com.example.app module.
D.It creates a JAR file containing the com.example.app module.
AnswerB

jlink resolves the module graph and includes all required modules.

Why this answer

Option C is correct. jlink resolves the specified module and its transitive dependencies, then creates a runtime image in the output directory. Option A is wrong because jlink does not compile; it uses pre-compiled modules. Option B is wrong because jlink includes all required modules, not just the specified one.

Option D is wrong because jlink produces a runtime image (directory), not a JAR file.

Practice this question →
38
MCQmedium

A company uses CI/CD to build and package a Java 17 application. They want to produce a single executable JAR that includes all dependencies. Which tool should be used to achieve this?

A.Maven JAR Plugin
B.Maven Shade Plugin
C.Java jar command
D.jlink tool
AnswerB

Maven Shade Plugin creates an uber-JAR with all dependencies.

Why this answer

The Maven Shade Plugin (B) is the correct choice because it creates an uber-JAR (fat JAR) by merging all project dependencies into a single executable JAR, including transitive dependencies. It also provides a relocation feature to avoid classpath conflicts, which is essential for producing a self-contained artifact for deployment.

Exam trap

The trap here is that candidates often confuse the Maven JAR Plugin (which only packages the project's own code) with the Shade Plugin (which bundles dependencies), or mistakenly think the Java jar command or jlink can automatically resolve and include Maven dependencies.

How to eliminate wrong answers

Option A is wrong because the Maven JAR Plugin only packages the compiled classes and resources of the project itself, without including any dependencies, so it cannot produce a single executable JAR with all dependencies. Option C is wrong because the Java jar command creates a standard JAR file from specified files and directories, but it does not automatically resolve or bundle dependencies from a build system like Maven or Gradle. Option D is wrong because jlink is a tool for creating a custom runtime image of the Java module system, not for packaging an application JAR with dependencies; it works with modular applications and requires explicit module declarations.

Practice this question →
39
MCQhard

A financial trading application is developed using Java 17 and the Java Platform Module System (JPMS). The application consists of 50 named modules, including third-party libraries that are automatic modules. The team uses jlink to create a custom runtime image for deployment on customer servers. They observe that the jlink process takes over 10 minutes and produces an image of 200 MB. They want to reduce both the build time and the image size. Which action would be most effective?

A.Use the --limit-modules option to restrict jlink to only the application's root modules.
B.Replace jlink with jpackage to create a platform-specific installer.
C.Use the --strip-java-debug-attributes option to remove debug information.
D.Add the --compress=2 option to the jlink command.
AnswerA

--limit-modules prevents jlink from resolving unnecessary transitive modules, drastically reducing both build time and image size.

Why this answer

Option D is correct because using --limit-modules restricts jlink's module resolution to only the explicitly specified modules and their dependencies, eliminating unnecessary module resolution and reducing the image size. Option A is wrong because --compress only compresses the image after resolution; it does not speed up resolution or significantly reduce the number of modules. Option B is wrong because stripping debug attributes has a minor impact on size and does not affect resolution time.

Option C is wrong because jpackage internally uses jlink and does not solve the fundamental issue of resolving too many modules.

Practice this question →
40
MCQeasy

In a modular Java application, where does the module declaration file typically reside?

A.In a file named module-info.class in the output directory
B.In the META-INF directory
C.In a file named module-info.java at the root of the module's source tree
D.In the root of the source directory
AnswerC

module-info.java is placed at the root of each module source tree.

Why this answer

Option C is correct because the module declaration for a modular Java application must be placed in a file named `module-info.java` at the root of the module's source tree. This file is then compiled into `module-info.class` and placed in the output directory, but the source declaration resides in the source tree root as per the Java Platform Module System (JPMS) specification.

Exam trap

The trap here is that candidates often confuse the source file location (`module-info.java` at the root of the source tree) with the compiled output (`module-info.class` in the output directory), or mistakenly think it belongs in `META-INF` due to familiarity with JAR metadata.

How to eliminate wrong answers

Option A is wrong because `module-info.class` is the compiled bytecode form of the module declaration, not the source file; the source file is `module-info.java`. Option B is wrong because the `META-INF` directory is used for metadata like `MANIFEST.MF` in JAR files, not for module declarations. Option D is wrong because while the root of the source directory is close, the module declaration must be specifically at the root of the module's source tree (i.e., the top-level package directory), not just any root directory.

Practice this question →
41
MCQmedium

A developer receives the above error when running a modular Java application. What is the most likely cause?

A.The module-info.java has a syntax error.
B.The module 'com.example.app' is not on the module path.
C.The JRE version is too old.
D.The main class is misspelled.
AnswerB

The error indicates the module was not found.

Why this answer

When a modular Java application throws an error indicating that a module cannot be found, the most common cause is that the module's JAR or directory is not present on the module path. The module path is specified using the `--module-path` option (or `-p`) when launching the application with `java --module`. If `com.example.app` is not on that path, the module system cannot resolve it, leading to a `ModuleNotFoundException` or similar error.

Exam trap

The trap here is that candidates confuse module path errors with classpath errors, assuming a missing class is the issue, when in fact the module system requires the entire module to be present on the module path.

How to eliminate wrong answers

Option A is wrong because a syntax error in module-info.java would produce a compilation error, not a runtime module resolution error. Option C is wrong because an outdated JRE version would typically cause `UnsupportedClassVersionError` or missing API errors, not a module-not-found error. Option D is wrong because a misspelled main class would result in a `ClassNotFoundException` or `NoClassDefFoundError`, not a module resolution failure.

Practice this question →
42
MCQmedium

A development team wants to ensure that a Java 17 application runs with a specific set of modules. They want to minimize the footprint by including only necessary modules. Which tool should they use?

A.javac
B.jlink
C.jmod
D.jar
AnswerB

jlink assembles a custom runtime image with specified modules.

Why this answer

B is correct because jlink is the Java tool specifically designed to assemble and optimize a custom runtime image containing only the modules explicitly required by an application. It analyzes module dependencies and produces a minimal JRE, reducing footprint by excluding unused modules, which aligns with the team's goal of minimizing size.

Exam trap

The trap here is that candidates confuse jlink with jmod or jar, assuming any packaging tool can minimize the runtime, but only jlink performs the module-aware linking and optimization to produce a custom JRE.

How to eliminate wrong answers

Option A is wrong because javac is the Java compiler that translates source code into bytecode; it does not create custom runtime images or manage module inclusion for deployment. Option C is wrong because jmod is used to create and inspect JMOD files, which are packaging formats for modules, but it cannot produce a runtime image or minimize the JRE footprint. Option D is wrong because jar is used to package class files and resources into JAR archives; it does not analyze module dependencies or generate a minimal runtime environment.

Practice this question →
43
MCQhard

A Java 17 application is deployed on a server. The application uses modules but one required module is missing from the module path. Which exception will be thrown at startup?

A.ExceptionInInitializerError
B.NoClassDefFoundError
C.ClassNotFoundException
D.ModuleNotFoundException
AnswerD

Thrown when a required module cannot be resolved.

Why this answer

Option D is correct because when a required module is missing from the module path in Java 17, the module system throws `ModuleNotFoundException` during the resolution phase at startup. This exception is specific to the Java Platform Module System (JPMS) and indicates that a module declared in `requires` clauses cannot be located.

Exam trap

The trap here is that candidates confuse module-level errors with class-level errors, mistakenly choosing `NoClassDefFoundError` or `ClassNotFoundException` because they think of missing JARs on the classpath, but the exam specifically tests the JPMS behavior where `ModuleNotFoundException` is the correct exception for a missing module on the module path.

How to eliminate wrong answers

Option A is wrong because `ExceptionInInitializerError` is thrown when an unexpected exception occurs in a static initializer, not when a module is missing from the module path. Option B is wrong because `NoClassDefFoundError` occurs when a class was present at compile time but is missing at runtime, typically due to classpath issues, not module resolution failures. Option C is wrong because `ClassNotFoundException` is thrown when an application tries to load a class via its string name using `Class.forName()`, `ClassLoader.loadClass()`, or similar reflective methods, not when the module system fails to find a module.

Practice this question →
44
MCQhard

A team uses 'jlink' to create a custom runtime image for a modular application. They run the following command: 'jlink --module-path $JAVA_HOME/jmods:myapp --add-modules com.example.myapp --output myimage'. The application requires several non-Java native libraries (e.g., .so files) that are loaded via System.loadLibrary(). After creating the image, the application fails with an UnsatisfiedLinkError. What is the most likely cause?

A.The native library loading requires a module that exports the package containing the native method.
B.The --add-modules flag omitted transitive dependencies of com.example.myapp.
C.The native libraries were not included in the image; they must be manually copied or added using --add-modules and a custom module.
D.The --module-path must also include the directories containing the native libraries.
AnswerC

jlink images only contain Java modules; native code must be placed in the appropriate directory (e.g., lib) or bundled via a module.

Why this answer

Option C is correct because the `jlink` tool creates a runtime image that includes only Java modules and their dependencies, not native libraries (e.g., .so files). Native libraries must be manually placed into the image's library path (e.g., `lib/` or `bin/` directory) or packaged into a custom module that is added via `--add-modules`. The `UnsatisfiedLinkError` occurs because `System.loadLibrary()` cannot find the native library in the image's expected locations.

Exam trap

The trap here is that candidates assume `jlink` automatically includes all dependencies, including native libraries, but `jlink` only handles Java modules and ignores non-Java artifacts like native `.so` or `.dll` files.

How to eliminate wrong answers

Option A is wrong because the `UnsatisfiedLinkError` is about the native library file not being found, not about module exports; exporting a package is irrelevant to native library loading. Option B is wrong because `--add-modules` with `com.example.myapp` automatically includes its transitive dependencies via the module descriptor; missing transitive dependencies would cause `ClassNotFoundException` or `NoClassDefFoundError`, not `UnsatisfiedLinkError`. Option D is wrong because `--module-path` is for Java module JARs and JMOD files, not native library directories; native libraries are not resolved via the module path.

Practice this question →
45
MCQmedium

A developer wants to include a module in a custom runtime image using jlink. The module's `module-info.java` does not explicitly export any packages. When running the application from the custom image, a ClassNotFoundException is thrown for a class from that module. What is the most likely cause?

A.The application does not require the module.
B.The module's packages are not exported, making them invisible to other modules.
C.The module uses an automatic module that is not present.
D.The module was not included in the jlink command.
AnswerB

Unexported packages are not accessible, causing ClassNotFoundException.

Why this answer

Option B is correct because if a module's `module-info.java` does not explicitly export any packages, those packages are not accessible to other modules at runtime. Even if the module is included in the custom runtime image via jlink, the `ClassNotFoundException` occurs because the class is not exported, making it invisible to other modules. The `jlink` tool includes the module's classes in the image, but without an `exports` directive, the packages remain encapsulated.

Exam trap

The trap here is that candidates assume including a module in the jlink command is sufficient to make all its classes accessible, but the Java module system enforces encapsulation at the package level, so without explicit `exports`, the classes are invisible to other modules.

How to eliminate wrong answers

Option A is wrong because the application may still `require` the module in its `module-info.java`, but that only grants compile-time and runtime access to the module's exported packages; if no packages are exported, requiring the module does not make its internal classes visible. Option C is wrong because the issue is about a named module with no exports, not about an automatic module; automatic modules export all their packages by default, so a missing automatic module would cause a different error (e.g., `ModuleNotFoundException`). Option D is wrong because if the module were not included in the jlink command, the custom image would not contain the module at all, leading to a `ModuleNotFoundException` or `NoClassDefFoundError` rather than a `ClassNotFoundException` for a class from that module.

Practice this question →
46
MCQmedium

A team is migrating a large legacy application from Java 8 to Java 17. The application consists of multiple JAR files that are placed on the classpath. Some of these JAR files have been updated to include module-info.class files, making them named modules. After migration, the application throws `IllegalAccessError` for several deep reflection calls that used to work in Java 8. The team has added `--add-opens` JVM flags to open the required packages, but the error persists. The application also uses a third-party library that is not modularized and is placed on the classpath. The team notices that the `--add-opens` flags are being ignored for packages in the modularized JARs. What is the most likely reason?

A.The `--add-opens` flags are being overridden by other JVM flags.
B.The application does not have a module-info.java file for its own code.
C.The modularized JARs are being loaded from the classpath, so they become unnamed modules, and `--add-opens` does not apply to unnamed modules.
D.The classpath is deprecated and ignored in Java 17, so all JARs are treated as modules.
AnswerC

`--add-opens` only applies to named modules. JARs on the classpath, even if they have module-info, are treated as unnamed modules if placed on the classpath. They must be on the module path to be named modules.

Why this answer

Option C is correct because when a JAR file containing a module-info.class is placed on the classpath instead of the module path, it is treated as an unnamed module. The `--add-opens` JVM flag only applies to named modules (those on the module path) and has no effect on unnamed modules. Since the modularized JARs are loaded from the classpath, they become unnamed modules, and the `--add-opens` flags are ignored, causing the `IllegalAccessError` to persist.

Exam trap

Oracle often tests the misconception that placing a modularized JAR on the classpath still makes it a named module, leading candidates to overlook the critical distinction between classpath (unnamed module) and module path (named module) in Java 9+.

How to eliminate wrong answers

Option A is wrong because there is no evidence or common mechanism by which other JVM flags would override `--add-opens`; these flags are additive and not overridden by default. Option B is wrong because the absence of a module-info.java for the application's own code does not cause `--add-opens` to be ignored; unnamed modules can still benefit from `--add-opens` if the target packages are in named modules, but here the target packages are in unnamed modules. Option D is wrong because the classpath is not deprecated or ignored in Java 17; it still works, but JARs on the classpath are treated as unnamed modules, not as named modules.

Practice this question →
47
Multi-Selectmedium

Which TWO statements about Java module types are true?

Select 2 answers
A.An automatic module exports all its packages.
B.An automatic module can access all packages of named modules without explicit requires.
C.The unnamed module can read only the java.base module.
D.A named module requires a module-info.java file at compile time.
E.The unnamed module is a named module.
AnswersA, D

Automatic modules export every package in the JAR.

Why this answer

Option A is correct because the Java module system automatically exports all packages of an automatic module, making them accessible to other modules without explicit export declarations. This is a key characteristic of automatic modules, which are created from JAR files placed on the module path without a module-info.java file.

Exam trap

The trap here is confusing the 'reads all other modules' capability of automatic modules with the ability to access all packages of those modules, when in fact only exported packages are accessible.

Practice this question →
48
MCQeasy

A developer has created a modular Java application. They want to distribute a minimal runtime image containing only the required modules. Which tool should they use?

A.javac
B.jlink
C.jar
D.jpackage
AnswerB

jlink creates a custom runtime image with only required modules.

Why this answer

B is correct because `jlink` is the Java tool specifically designed to assemble and optimize a minimal runtime image containing only the modules explicitly required by the application and its transitive dependencies. It links the specified modules and their dependencies into a custom JRE that excludes unused modules, reducing footprint for distribution.

Exam trap

The trap here is that candidates confuse `jpackage` (which creates installers) with `jlink` (which creates the runtime image), or assume `jar` can produce a runnable image because it can create executable JARs with a manifest.

How to eliminate wrong answers

Option A is wrong because `javac` is the Java compiler that translates source code into bytecode; it does not create runtime images or handle module linking. Option C is wrong because `jar` packages compiled classes and resources into a JAR archive, but it cannot produce a standalone runtime image with a custom JRE. Option D is wrong because `jpackage` packages a self-contained application installer for a target platform, but it relies on `jlink` internally to create the runtime image; the question asks for the tool to create the minimal runtime image itself, not the installer.

Practice this question →
49
MCQhard

A developer is migrating a classpath-based application to modules. They have two JARs on the classpath that both contain a package with the same name, com.example.util. When they move both JARs to the module path, they encounter a module resolution error. What is the most likely cause?

A.The --add-exports option is missing
B.Named modules cannot have split packages
C.The JARs need to be merged into one module
D.Automatic modules cannot have split packages
AnswerB

Both JARs become automatic modules (named), and split packages are disallowed among named modules.

Why this answer

In the Java module system, a package can be defined in at most one module on the module path. When both JARs contain com.example.util, moving them to the module path creates a split package, which is illegal for named modules. The module system enforces this to ensure reliable configuration and encapsulation, resulting in a module resolution error.

Exam trap

Oracle often tests the distinction between named modules and automatic modules, and the trap here is that candidates incorrectly assume automatic modules have the same split-package restrictions as named modules, when in fact automatic modules are more lenient to ease migration.

How to eliminate wrong answers

Option A is wrong because --add-exports is used to export a package from a module to another module at runtime, not to resolve split packages; the error occurs at module resolution, not at access time. Option C is wrong because merging the JARs into one module is a possible solution, but the question asks for the most likely cause of the error, not the fix; the cause is the split package violation. Option D is wrong because automatic modules can indeed have split packages with other automatic modules or with the unnamed module; the restriction against split packages applies strictly to named modules.

Practice this question →
50
Multi-Selectmedium

Which TWO statements are true about Java modules in Java 17? (Choose two.)

Select 2 answers
A.A module can export a package only to specific modules using 'exports ... to ...'
B.The module-info.java file must be compiled with javac and placed in the root of the JAR.
C.All packages in a module are automatically exported.
D.The jdeps tool can be used to create a module graph.
E.The jlink tool creates a JAR file containing the module.
AnswersA, B

Qualified exports limit access to specified modules.

Why this answer

Option A is correct because the 'exports ... to ...' directive in module-info.java restricts the exported package to only the specified target modules, providing fine-grained access control. This is a key feature of the Java module system introduced in Java 9, allowing a module to expose its packages only to trusted modules rather than all other modules.

Exam trap

Oracle often tests the misconception that all packages in a module are automatically exported, but in reality, only explicitly exported packages are accessible outside the module, and the jlink tool creates a runtime image, not a JAR file.

Practice this question →
51
MCQhard

An application uses `--add-opens java.base/java.lang=ALL-UNNAMED` to allow reflective access to `java.lang` internals from the classpath. After migrating to a module, the flag is changed to `--add-opens java.base/java.lang=com.example.app`. Yet reflective access still fails with `InaccessibleObjectException`. What is the most likely reason?

A.The class performing reflection is in an unnamed module.
B.The module does not read the module java.base.
C.The module name in --add-opens is misspelled.
D.The reflective call is made from a different module than com.example.app.
AnswerD

--add-opens opens only for the specified target module(s); if the code is in another module, it fails.

Why this answer

Option D is correct because `--add-opens` specifies which module's package is opened to which target module. When the flag is changed from `ALL-UNNAMED` to `com.example.app`, only code in the `com.example.app` module is granted reflective access. If the reflective call originates from a different module (e.g., a third-party library or another application module), the `InaccessibleObjectException` will still be thrown because that module is not listed as the target.

Exam trap

The trap here is that candidates assume `--add-opens` with a specific module name opens the package to all modules, when in fact it only opens to the named module, and the reflective caller must belong to that exact module.

How to eliminate wrong answers

Option A is wrong because the class performing reflection is now in a named module (the application was migrated to a module), not an unnamed module; the flag targets `com.example.app`, so if the reflective class were unnamed, the flag would need `ALL-UNNAMED`. Option B is wrong because every module implicitly reads `java.base` (it is the base module), so the module does read `java.base`; the issue is not about reading but about opening packages. Option C is wrong because the question states the flag is changed to `--add-opens java.base/java.lang=com.example.app`, and if it were misspelled, the JVM would typically emit a warning or fail to parse, but the error described is a runtime `InaccessibleObjectException`, not a startup failure; the most likely cause is a module mismatch.

Practice this question →
52
MCQmedium

Refer to the exhibit. Which statement is true about the com.example.app.internal package?

A.It is accessible for deep reflection only by com.example.lib.
B.It is accessible for deep reflection by any module.
C.It is not accessible for reflection at all.
D.It is exported to all modules.
AnswerA

The opens ... to directive grants reflective access to the named module only.

Why this answer

Option A is correct because the exhibit shows that `com.example.app.internal` is declared with `opens com.example.app.internal to com.example.lib`. The `opens` directive grants deep reflection (access to private members) at runtime, but only to the specified module `com.example.lib`. Other modules cannot reflectively access this package unless they are explicitly listed.

Exam trap

Oracle often tests the distinction between `exports` (compile-time and runtime access to public types) and `opens` (runtime reflective access, including private members), and the trap here is that candidates confuse `opens` with `exports` or assume `opens` grants access to all modules unless a `to` clause is specified.

How to eliminate wrong answers

Option B is wrong because the `opens` directive restricts deep reflection to only `com.example.lib`, not to any module. Option C is wrong because the package is explicitly opened to `com.example.lib`, so reflection is allowed for that module. Option D is wrong because the package is not exported; it is only opened for reflection, meaning it is not accessible at compile time or via direct code access from other modules.

Practice this question →
53
MCQeasy

A developer places a non-modular JAR file on the module path. What type of module does this JAR become?

A.Open module
B.Named module
C.Automatic module
D.Unnamed module
AnswerC

A JAR on the module path without module-info becomes an automatic module.

Why this answer

When a non-modular JAR is placed on the module path, the Java module system automatically derives a module from it, known as an automatic module. This is because the JAR lacks a module-info.class, so the system infers a module name from the JAR filename (e.g., using the Main-Class attribute or the JAR's name) and exports all packages, giving it access to all other modules. Option C is correct because the JAR becomes an automatic module, not a named or unnamed module.

Exam trap

The trap here is that candidates confuse the module path with the classpath, mistakenly thinking a non-modular JAR on the module path becomes an unnamed module, when in fact it becomes an automatic module with special privileges like reading all other modules.

How to eliminate wrong answers

Option A is wrong because an open module is a named module that explicitly uses the 'open' keyword in its module-info.java to allow deep reflection at runtime, which is not applicable to a non-modular JAR. Option B is wrong because a named module requires a module-info.class file (either compiled from module-info.java or a module-info.class in the JAR), which a non-modular JAR does not have. Option D is wrong because an unnamed module is created when a JAR is placed on the classpath, not the module path; placing a JAR on the module path triggers automatic module creation, not unnamed module behavior.

Practice this question →
54
MCQmedium

A Java 17 application is packaged as a modular jar and deployed on a system with the full JDK. The application uses the java.sql module. The system administrator wants to minimize the footprint by creating a custom runtime image using jlink. Which command would create an image with only the necessary modules?

A.jlink --module-path $JAVA_HOME/jmods:app --add-modules com.myapp --output myimage
B.jlink --module-path $JAVA_HOME/jmods:app --add-modules com.myapp --bind-services --output myimage
C.jlink --module-path $JAVA_HOME/jmods:app --add-modules java.sql --output myimage
D.jlink --module-path $JAVA_HOME/jmods:app --add-modules ALL-MODULE-PATH --output myimage
AnswerA

This adds the application module and its transitive dependencies, including java.sql if required.

Why this answer

Option A is correct because `jlink` with `--add-modules com.myapp` and the module path pointing to both `$JAVA_HOME/jmods` and the application JAR automatically resolves all transitive dependencies, including `java.sql`, and creates a minimal runtime image containing only the required modules. The `--output myimage` specifies the target directory for the custom image.

Exam trap

The trap here is that candidates often think `--bind-services` is required for modular applications or that explicitly listing `java.sql` is sufficient, but they overlook that the application module itself must be the root for proper dependency resolution.

How to eliminate wrong answers

Option B is wrong because `--bind-services` adds service provider modules that are not strictly necessary for the application's direct dependencies, potentially increasing the image footprint beyond the minimal set. Option C is wrong because it explicitly adds only `java.sql` without including the application module `com.myapp`, so the image would lack the application itself and its transitive dependencies. Option D is wrong because `ALL-MODULE-PATH` includes every module found on the module path, which defeats the purpose of minimizing the footprint by creating a full-sized image.

Practice this question →
55
Multi-Selectmedium

Which TWO statements about module descriptors are true?

Select 2 answers
A.A module descriptor can use the provides keyword to declare that it uses a service.
B.A module descriptor can use the opens keyword to enable deep reflection on specific packages.
C.A module descriptor must require the java.base module explicitly.
D.A module descriptor can specify which packages are exported with the export keyword.
E.A module descriptor can use the transitive keyword only with requires directives.
AnswersB, E

opens grants reflective access to all types in the package.

Why this answer

Option B is correct because the `opens` keyword in a module descriptor (module-info.java) allows deep reflection (access to private members) on specific packages at runtime, which is necessary for frameworks like Hibernate or JPA that rely on reflection. Option E is correct because the `transitive` keyword is used only within `requires` directives to indicate that any module that requires the current module also implicitly requires the specified module.

Exam trap

The trap here is confusing the `provides` and `uses` keywords (service provider vs. service consumer) and mistaking the `export` keyword for the correct `exports` keyword, which is a common syntax error in module descriptors.

Practice this question →
56
Multi-Selectmedium

Which TWO statements are true about the Java module system?

Select 2 answers
A.The --add-exports command-line flag opens a package for deep reflection.
B.The --add-exports flag can be used to export a package from one module to a specific target module.
C.The jlink tool can generate module-info.java files for automatic modules.
D.A named module must have a module-info.java file in its root directory.
E.The exports directive can be used to export a specific class to another module.
AnswersB, D

It allows a module to access the public types of a package in another module.

Why this answer

Option B is correct because the --add-exports command-line flag allows you to export a package from one module to a specific target module at runtime, overriding the module system's encapsulation. This is useful for modules that do not export a package by default but need to be accessed by a specific module during development or testing.

Exam trap

Oracle often tests the distinction between --add-exports (for type access) and --add-opens (for deep reflection), and the fact that exports are at the package level, not class level, causing candidates to confuse these concepts.

Practice this question →
57
MCQeasy

A developer has written a Java class that uses external libraries packaged as JAR files. The application runs correctly when launched from an IDE but fails with a ClassNotFoundException when run from the command line using `java -cp`. What is the most likely cause?

A.The JAR files are not listed in the classpath argument.
B.The classpath is missing the directory containing the class files.
C.The JAR files are not in the module path.
D.The Java command should use java -jar instead.
AnswerA

The classpath must explicitly list all required JAR files.

Why this answer

When running a Java application from the command line with `java -cp`, the classpath must explicitly include all JAR files and directories containing the required classes. If the external library JARs are not listed in the `-cp` argument, the class loader cannot find them, resulting in a `ClassNotFoundException`. IDEs typically manage the classpath automatically, which is why the application works there but fails from the command line.

Exam trap

The trap here is that candidates may confuse the classpath with the module path, or assume that `java -jar` automatically resolves all dependencies, when in fact it only reads the `Class-Path` manifest entry and does not combine with `-cp` unless explicitly set.

How to eliminate wrong answers

Option B is wrong because the classpath missing the directory containing the class files would cause a different error (e.g., the main class not being found), not a `ClassNotFoundException` for external library classes. Option C is wrong because the module path is used for modular Java applications (Java 9+ modules), not for traditional classpath-based JARs; the `-cp` flag is the correct mechanism for non-modular JARs. Option D is wrong because `java -jar` is used when the JAR has a `Main-Class` attribute in its manifest and you want to run an executable JAR; it does not automatically include other JARs in the classpath, so the same `ClassNotFoundException` would occur if the external libraries are not specified via `-cp` or the `Class-Path` manifest entry.

Practice this question →
58
Multi-Selecthard

Which THREE are valid ways to package a Java 17 application for distribution? (Choose three.)

Select 3 answers
A.JMOD file
B.ZIP file containing compiled classes
C.Native installer (e.g., MSI, DMG)
D.Shell script that compiles and runs the application
E.JAR file with a manifest
AnswersA, C, E

JMOD is a packaging format for modules.

Why this answer

A is correct because a JMOD file is a native packaging format introduced in Java 9 (JEP 261) specifically for distributing Java modules. It can include compiled classes, native code, configuration files, and even other JMOD files, making it a valid distribution format for Java 17 applications, especially when using the Java Module System.

Exam trap

The trap here is that candidates often confuse a 'distribution package' with a 'build artifact' or 'source code delivery', leading them to select options like a ZIP of classes or a shell script, which are not valid packaging formats for end-user distribution.

Practice this question →
59
MCQmedium

You are a DevOps engineer at a software house. Your team is preparing a Java 17 application for deployment. The application is modular and consists of 12 modules. They have been using the 'jlink' tool to create a custom runtime image for Linux. The image works fine on the development machines. However, when deployed to a minimal Docker container based on Alpine Linux, the application fails with: 'Error: Could not find or load main class com.example.Main'. The main class is declared in the module 'com.example.app' and the module-path is correctly set within the image. The image's bin directory contains the launcher scripts generated by jlink. The Docker container has only the bare minimum libraries. You have verified that the 'modules' file exists in the lib directory and contains 'com.example.app'. What is the most likely cause?

A.The launcher script in the image has a bash shebang and Alpine uses ash, causing the script to fail to execute properly.
B.The main class is not exported by the module, so the launcher cannot find it.
C.The Alpine container is missing the glibc compatibility layer, causing the JVM to fail loading native libraries.
D.The module path in the launcher script does not include the application module.
AnswerA

Jlink-generated scripts often start with #!/bin/bash. Alpine's default shell is ash; if bash is not installed, the script fails, leading to the class loading error because the java command is not invoked correctly.

Why this answer

The jlink tool generates launcher scripts with a bash shebang (#!/bin/bash) by default. Alpine Linux uses ash (a BusyBox shell) instead of bash, and if bash is not installed in the minimal container, the script fails to execute properly, resulting in the 'Could not find or load main class' error even though the module path and modules file are correct.

Exam trap

The trap here is that candidates often focus on module system details (exports, module path) or native library compatibility, overlooking the fact that the launcher script itself may fail to execute due to the absence of bash in a minimal Alpine container, which produces a misleading error message about the main class.

How to eliminate wrong answers

Option B is wrong because the main class does not need to be exported; it only needs to be declared in the module-info.java with a 'main class' directive or specified via the --main-class option when creating the launcher. Option C is wrong because the error message specifically mentions the main class not being found, not a native library loading failure; Alpine uses musl libc, and while glibc compatibility can cause issues, the given error is not indicative of that. Option D is wrong because the problem statement explicitly says the module-path is correctly set within the image and the modules file contains the application module, so the module path is not the issue.

Practice this question →
60
Multi-Selecteasy

Which TWO are characteristics of a multi-release JAR (MR-JAR)?

Select 2 answers
A.The root of the JAR contains classes for the oldest supported version.
B.The version directory must be named with the full version string like "9.0.4".
C.It uses the META-INF/versions/ directory structure.
D.It can only contain a single version of each class.
E.It is created using the jlink tool.
AnswersA, C

Root provides the base version for platforms that don't support MR-JAR.

Why this answer

Option A is correct because in a multi-release JAR (MR-JAR), the root of the JAR contains the classes compiled for the oldest supported Java version. This ensures backward compatibility: when the JAR is run on an older JVM that does not understand the META-INF/versions directory, it will use the classes from the root. The JVM automatically selects the appropriate versioned class from the META-INF/versions/<version>/ directory based on the major version of the running Java runtime.

Exam trap

The trap here is that candidates often confuse the version directory naming convention, assuming it uses a full version string like '9.0.4' instead of the correct major version number (e.g., '9'), or they mistakenly think an MR-JAR can only hold one version of each class.

Practice this question →
61
MCQeasy

A developer runs `java --list-modules` and sees the above output on a standard JDK installation. What does this output represent?

A.The modules that are part of the java.base module.
B.The modules that are required by the current application.
C.The set of modules available in the current JDK.
D.The modules that are currently loaded by the JVM.
AnswerC

It lists all modules that can be resolved.

Why this answer

The `java --list-modules` command outputs the names of all observable modules that are part of the current JDK installation. This includes all platform modules (e.g., `java.base`, `java.sql`, `jdk.compiler`) that are available for use, regardless of whether they are currently required or loaded by an application. Option C correctly identifies this as the set of modules available in the current JDK.

Exam trap

The trap here is that candidates confuse 'available modules' with 'loaded modules' or 'required modules', because in everyday development, the modules used by an application are often a subset of those available, but `--list-modules` shows the full set of observable modules in the JDK, not the runtime state.

How to eliminate wrong answers

Option A is wrong because `java.base` is just one specific module, not the list of all modules; `--list-modules` shows all platform modules, not just those in `java.base`. Option B is wrong because the command does not depend on any application; it lists all modules in the JDK, not only those required by the current application. Option D is wrong because `--list-modules` shows available modules, not currently loaded modules; modules are loaded lazily by the JVM at runtime, and this command does not trigger loading.

Practice this question →
62
Drag & Dropmedium

Arrange the steps to read a file using NIO.2 Files.lines() in Java.

Drag steps to the numbered slots on the right, or tap a step then tap a slot.

Steps
Order

Why this order

Files.lines() returns a Stream that must be closed to release file handles. The stream is lazily populated.

Practice this question →
63
MCQhard

You are a software architect at a financial firm. Your team is developing a modular Java 17 application that comprises several modules: 'com.bank.core' (provides core banking services), 'com.bank.web' (REST API), and 'com.bank.persistence' (database access). The application uses the 'java.sql' module for JDBC and 'java.logging' for logging. The team uses Maven for dependency management. The application has an external dependency on the 'com.fasterxml.jackson.databind' library (Jackson) for JSON processing, which is provided as a non-modular jar. The Jackson jar is placed on the module path. The application modules are all named modules with module-info files. At runtime, the 'com.bank.web' module requires 'com.bank.core' and 'com.fasterxml.jackson.databind' (the automatic module). The 'com.bank.core' module requires 'java.sql' and 'java.logging'. When the application runs, it throws an 'IllegalAccessError' indicating that the module 'com.bank.core' tries to access a class from 'com.fasterxml.jackson.databind' but the module does not read it. Yet, 'com.bank.web' is the only module that explicitly requires Jackson. What is the most likely cause and the correct resolution?

A.Convert all application modules to unnamed modules by removing module-info files.
B.Add 'requires com.fasterxml.jackson.databind' to the module-info.java of 'com.bank.core' because it uses Jackson classes directly.
C.Place the Jackson jar on the classpath instead of the module path.
D.Use jlink to create a custom runtime image including all modules and the Jackson jar.
AnswerB

Direct use requires a requires directive; this resolves the readability chain.

Why this answer

Option B is correct because the error indicates that 'com.bank.core' directly uses classes from 'com.fasterxml.jackson.databind', but its module-info.java does not include a 'requires com.fasterxml.jackson.databind' directive. In the Java module system, a module can only access types from another module if it explicitly reads that module. Since 'com.bank.core' needs Jackson classes at runtime, it must declare the dependency itself, even if another module ('com.bank.web') also requires it.

Exam trap

The trap here is that candidates assume transitive dependencies are automatically resolved by the module system, but in Java modules, each module must explicitly declare its own 'requires' for any module it directly uses, even if another module already requires it.

How to eliminate wrong answers

Option A is wrong because converting all modules to unnamed modules by removing module-info files would defeat the purpose of modularization, breaking encapsulation and potentially causing classpath conflicts; it does not fix the missing 'requires' directive. Option C is wrong because placing the Jackson jar on the classpath instead of the module path would make it an unnamed module, which would still not grant 'com.bank.core' read access to Jackson's packages unless the module reads the unnamed module (via 'requires java.base' or '--add-reads'), and it would also lose the benefits of reliable configuration. Option D is wrong because using jlink to create a custom runtime image does not resolve the missing module readability; jlink only includes modules that are explicitly required, and if 'com.bank.core' does not require Jackson, the error persists.

Practice this question →
64
Multi-Selectmedium

Which THREE statements are true about the Java Platform editions? (Select three.)

Select 3 answers
A.Java ME provides a subset of Java SE APIs for embedded devices.
B.Java SE (Standard Edition) provides the core APIs for developing general-purpose Java applications.
C.Java ME (Micro Edition) is the same as Android SDK.
D.Java EE (now Jakarta EE) extends Java SE with APIs for distributed computing and web services.
E.Java SE includes a full application server for enterprise applications.
AnswersA, B, D

Java ME is designed for small devices with limited resources.

Why this answer

Java ME (Micro Edition) is designed for resource-constrained devices like sensors, mobile phones, and embedded systems. It provides a subset of the Java SE APIs, along with additional APIs tailored for small devices, such as the Connected Limited Device Configuration (CLDC) and the Mobile Information Device Profile (MIDP). This allows developers to write Java applications that run on devices with limited memory, processing power, and display capabilities.

Exam trap

The trap here is confusing Java ME with Android's SDK, as both target mobile/embedded devices, but Android uses a completely different runtime and API set, while Java ME is a standardized Java platform under the Java Community Process (JCP).

Practice this question →
65
Matchingmedium

Match each Java 17 feature to its description.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts
Matches

Restricts which classes can extend or implement a type

Allows patterns in case labels for type checks and destructuring

Transparent carriers for immutable data

Multi-line string literals with automatic formatting

Switch that can be used as an expression and returns a value

Why these pairings

These are key features introduced or enhanced in recent Java versions including 17.

Practice this question →
66
MCQhard

A developer runs 'jdeps -s --module-path lib myapp.jar' and gets output: 'myapp.jar -> java.base, myapp.jar -> java.sql, myapp.jar -> notfound'. What does the 'notfound' entry indicate?

A.The application has a dependency on a package that is not provided by any module on the module path.
B.The dependency is resolved but its module name is not printed due to a summary flag.
C.The jar file is missing or corrupt.
D.There is a cyclic dependency among modules.
AnswerA

The 'notfound' indicates an unknown dependency that cannot be resolved to any module.

Why this answer

The 'notfound' entry in the jdeps -s output indicates that the application has a dependency on a package that is not provided by any module on the module path. The -s (summary) flag shows module-level dependencies, and when a required module cannot be located among the specified modules or the JDK's built-in modules, jdeps reports it as 'notfound'. This means the dependency cannot be resolved at analysis time, typically because the required module is missing from the module path.

Exam trap

The trap here is that candidates may confuse 'notfound' with a missing JAR file or a corrupt archive, but jdeps specifically reports unresolved module dependencies, not file system errors.

How to eliminate wrong answers

Option B is wrong because the -s (summary) flag does not suppress module names; it merely shortens the output to show only module-level dependencies without package details, so a resolved dependency would still show its module name. Option C is wrong because a missing or corrupt JAR file would cause jdeps to fail with an error message, not produce a 'notfound' entry in the dependency output. Option D is wrong because cyclic dependencies among modules are reported differently by jdeps (e.g., with a cycle warning), not as 'notfound'.

Practice this question →
67
MCQmedium

A developer runs the above jdeps command on app.jar. Which statement about the dependencies is correct?

A.The app.jar has a direct dependency on the class com.thirdparty.util.
B.The modular dependency com.thirdparty.helper is not required because it is modular.
C.The dependencies on com.thirdparty.util and com.thirdparty.helper are on the module path.
D.The app.jar depends on java.base implicitly.
AnswerD

All Java applications implicitly depend on java.base.

Why this answer

Option D is correct because every Java module automatically has an implicit dependency on the `java.base` module, which is always resolved by the module system. The `jdeps` command analyzes dependencies, and even if no explicit `requires java.base` is declared, the module system adds it implicitly. This is a fundamental rule of the Java Platform Module System (JPMS) as defined in JSR 376.

Exam trap

Oracle often tests the implicit dependency on `java.base` to catch candidates who think all module dependencies must be explicitly declared in `module-info.java`.

How to eliminate wrong answers

Option A is wrong because `jdeps` output shows dependencies at the package level, not the class level; it would report a dependency on the package `com.thirdparty.util`, not on a specific class. Option B is wrong because whether a dependency is modular or not does not affect whether it is required; if `app.jar` uses types from `com.thirdparty.helper`, it must have a direct or transitive dependency on that module, regardless of its modular status. Option C is wrong because `jdeps` does not indicate whether dependencies are on the module path; it only reports the dependencies found, not their location (module path vs. class path).

Practice this question →
68
MCQhard

An application built with Java 17 uses a third-party library that internally uses `sun.misc.Unsafe`. The application runs without errors on Java 8 but throws an `IllegalAccessError` on Java 17. What is the most likely reason?

A.The --illegal-access flag is set to permit.
B.Strong encapsulation of JDK internals is enforced by default.
C.The module path does not include the library.
D.The library is not in a named module.
AnswerB

Java 17 strongly encapsulates internal APIs by default, causing IllegalAccessError.

Why this answer

In Java 17, strong encapsulation of JDK internals is enforced by default, meaning that code cannot access internal APIs like `sun.misc.Unsafe` via reflection or direct use unless explicitly opened. The `IllegalAccessError` occurs because the third-party library attempts to use `sun.misc.Unsafe`, which is a JDK internal API that is no longer accessible by default. This change was introduced as part of JEP 403 (Strongly Encapsulate JDK Internals) and finalized in Java 17, whereas Java 8 allowed such access.

Exam trap

The trap here is that candidates may think the error is due to the library not being modular (Option D) or a missing module path (Option C), but the real cause is the default strong encapsulation of JDK internals in Java 17, which is a direct consequence of JEP 403.

How to eliminate wrong answers

Option A is wrong because the `--illegal-access=permit` flag was a Java 9–16 transitional option that allowed access to internal APIs; in Java 17, this flag is no longer supported and defaults to `deny`, so setting it to `permit` would not change the behavior. Option C is wrong because the module path not including the library would cause a `ModuleNotFoundException` or `ClassNotFoundException`, not an `IllegalAccessError`; the error here is about access control, not missing modules. Option D is wrong because the library not being in a named module (i.e., being on the classpath) actually makes it more likely to be subject to strong encapsulation, but the error is not about module naming; the core issue is that `sun.misc.Unsafe` is an internal API that is encapsulated regardless of whether the library is named or unnamed.

Practice this question →
69
MCQhard

A Java 17 application is packaged as a JAR with a Main-Class manifest entry. The JAR is run using 'java -jar app.jar'. However, the application throws a NoClassDefFoundError for a class that is inside the JAR. What is the most likely cause?

A.The class is not exported from its module
B.The Main-Class manifest entry is incorrect
C.The JAR file is corrupt
D.The classpath is not set
AnswerC

A corrupt JAR may have missing or damaged entries.

Why this answer

Option C is correct because a NoClassDefFoundError for a class that is inside the JAR indicates that the class file exists in the JAR manifest but cannot be loaded due to corruption. When using 'java -jar', the JVM reads the JAR file directly; if the JAR is corrupt (e.g., truncated, CRC mismatch, or invalid ZIP entry), the class loader fails to read the class bytes, throwing NoClassDefFoundError even though the class is listed in the JAR.

Exam trap

Oracle often tests the distinction between NoClassDefFoundError (class existed at compile time but not at runtime) and ClassNotFoundException (class never found), and the trap here is that candidates incorrectly attribute the error to classpath issues (Option D) or module exports (Option A) when the class is actually inside the JAR but unreadable due to corruption.

How to eliminate wrong answers

Option A is wrong because the class is inside the JAR and not in a named module; module export rules only apply to modular JARs with module-info.class, and a non-modular JAR on the classpath has no module boundaries. Option B is wrong because if the Main-Class manifest entry were incorrect, the JVM would throw a 'Main class not found' or 'Could not find or load main class' error, not a NoClassDefFoundError for a dependency class. Option D is wrong because when using 'java -jar', the classpath is ignored; the JVM only uses the JAR's own entries and does not consult the -cp or CLASSPATH environment variable.

Practice this question →

Ready to test yourself?

Try a timed practice session using only Java Platform Overview and Packaging questions.

Start 20-question session