SaveMyCert
Log in
5 of 5 free questions left today·for 30 a day
1Z0-831 · Domain 7

Packaging and Deploying Java Code practice questions

Packaging and Deploying Java Code is worth 9% of the 1Z0-831 exam — the 5th-heaviest of the 10 domains. Modules, services and module imports; compiling and running source (compact source files, instance main), JARs, runtime images and migration to modules. Oracle publishes no domain weights; weight approximates the objective share, with a floor for every section. 6 fully worked examples are further down this page, answers included.

Exam weight
9%
the 5th-heaviest of the 10 domains
Questions
86
across 2 topics
Free, no account
5/day
a free account allows 30 a day
Explanations
Every option
right and wrong

Build a practice session

5 free questions left today.

Domains

How many?

Mode

Ready when you are

10 fresh questions drawn across 1 of 10 domains, in Learn mode.

Focused review

Every question you answer incorrectly, and every question you flag while practising, is saved here automatically. Finish a session and you can come back to re-drill just those.

6 sample Packaging and Deploying Java Code questions, fully explained

Questions from the 1Z0-831 bank mapped to domain 7, with the answer key and the reasoning behind every option. None of them repeat the examples on the main 1Z0-831 practice page.

Question 1Packaging and Deploying Java Code

Given these files:// lib/com/shop/api/Cart.java package com.shop.api; public class Cart { } // lib/com/shop/api/spi/Pricing.java package com.shop.api.spi; public interface Pricing { } // app/module-info.java module app { requires lib; } // app/app/Main.java package app; import com.shop.api.Cart; import com.shop.api.spi.Pricing; public class Main { public static void main(String[] args) { Cart c = new Cart(); Pricing p = null; System.out.println("ok"); } }Which two declarations of module lib let both modules compile so that app prints ok? (Select TWO.)

Choose TWO.

  • a
    module lib { exports com.shop.api; exports com.shop.api.spi.*; }

    The first directive is fine, but exports takes a single package name with no wildcard form, so javac reports '<identifier> expected' at the asterisk and nothing compiles.

  • b
    module lib { exports com.shop.api; }

    Exporting a package does not export its subpackages. com.shop.api.spi is a separate package, so the import of Pricing fails.

  • c
    module lib { exports com.shop.api; exports com.shop.api.spi; } Correct

    Each package is exported by its own directive, so both Cart and Pricing are visible to app, which reads lib.

  • d
    module lib { exports com.shop.api; opens com.shop.api.spi to app; }

    A qualified opens grants app reflective access at run time only. It does not make com.shop.api.spi accessible to the compiler, so the import of Pricing fails with 'package com.shop.api.spi is not visible'.

  • e
    open module lib { exports com.shop.api; exports com.shop.api.spi; } Correct

    An open module may still contain exports directives. open only adds runtime deep-reflective access to every package; the two exports give app compile-time access to both packages.

The concept

An exports directive names exactly one package. Subpackages are separate packages, and opens is a run-time reflection grant, not a compile-time export.

Why that’s the answer

Java has no package hierarchy as far as modules are concerned: com.shop.api.spi is unrelated to com.shop.api, so it needs its own exports directive. The plain module with two exports works, and so does the open module with the same two exports, because open adds deep reflection on top without removing exports. The wildcard is not legal syntax, the single export leaves Pricing invisible, and opens does not help javac.

How to reason it out
  1. Identify the packages app imports from: com.shop.api and com.shop.api.spi.
  2. Check that each is named by its own exports directive.
  3. Reject syntax that module declarations do not have, such as a wildcard.
  4. Remember that opens affects reflection at run time, not compilation.

Exam tip: One exports directive per package; subpackages are never exported implicitly.

Java Modules, Services and Module Imports (1Z0-831) — the lesson that teaches this.

Question 2Packaging and Deploying Java Code

Module lib contains packages lib.api and lib.impl. Modules tools and app both declare requires lib. The team wants any module to compile against lib.api, but only tools to compile against lib.impl; a reference to lib.impl from app must be a compile-time error. Which declaration of lib meets this requirement?

Choose one.

  • a
    module lib { exports lib.api; exports lib.impl to tools; } Correct

    lib.api is exported to every module that reads lib, and the qualified export makes lib.impl accessible to tools alone. app still compiles against lib.api but not lib.impl.

  • b
    module lib { exports lib.api to tools; exports lib.impl; }

    This swaps the two scopes: lib.impl becomes visible to every module, including app, while app loses lib.api.

  • c
    module lib { exports lib.api; opens lib.impl to tools; }

    A qualified opens gives tools reflective access at run time only. The compiler still treats lib.impl as unexported, so code in tools that names lib.impl types does not compile.

  • d
    module lib { exports lib.api, lib.impl to tools; }

    An exports directive takes one package; a comma-separated package list is a syntax error. Only the module list after to may contain several names.

The concept

A qualified export (exports p to m1, m2) makes a package accessible only to the named modules; an unqualified export makes it accessible to every module that reads the exporting module.

Why that’s the answer

The requirement has two scopes: lib.api for everyone, lib.impl for tools only. That is one unqualified export and one qualified export. Swapping them inverts the scopes; a qualified opens is a run-time reflection grant that javac ignores for type access; and listing two packages in one exports directive is not valid syntax.

How to reason it out
  1. Map each package to who may use it: lib.api to all, lib.impl to tools.
  2. Use a plain exports for the package everyone may use.
  3. Use exports ... to tools for the restricted package.
  4. Discard opens when the requirement is compile-time access.

Exam tip: exports p to m restricts compile-time and run-time access to the named modules; opens never grants compile-time access.

Java Modules, Services and Module Imports (1Z0-831) — the lesson that teaches this.

Question 3Packaging and Deploying Java Code

Given:// lib/module-info.java module lib { exports lib.api; exports lib.impl to mid; } // lib/lib/api/Names.java package lib.api; public class Names { public static String first() { return "A"; } } // lib/lib/impl/Cache.java package lib.impl; public class Cache { public static int size() { return 1; } } // mid/module-info.java module mid { requires transitive lib; } // app/module-info.java module app { requires mid; } // app/app/Main.java package app; public class Main { public static void main(String[] args) { System.out.print(lib.api.Names.first()); System.out.print(lib.impl.Cache.size()); } }All modules are compiled together with javac --module-source-path, and the program is launched with java -p out -m app/app.Main. What is the result?

Choose one.

  • a
    It prints A1.

    app does read lib through mid's requires transitive, but readability alone is not access: lib.impl is exported only to mid, so the Cache reference is rejected.

  • b
    Compilation fails at the Cache reference only. Correct

    app reads lib by implied readability, so the Names call in the exported lib.api compiles. lib.impl is exported to mid alone, so javac reports that lib does not export lib.impl to module app.

  • c
    Compilation fails at both the Names and Cache references.

    requires transitive lib in mid means every module that reads mid also reads lib, so lib.api.Names is accessible to app without app naming lib.

  • d
    It prints A, then throws IllegalAccessError.

    The qualified export is enforced by javac as well as the JVM, so the program never compiles and nothing is printed.

The concept

Implied readability (requires transitive) passes on readability, but a qualified export still limits access to the modules it names.

Why that’s the answer

Two independent checks apply to each reference from app. Readability: app requires mid, and mid requires transitive lib, so app reads lib. Export: lib.api is exported to everyone, so Names is accessible; lib.impl is exported only to mid, so Cache is not accessible to app even though app reads lib. Only the Cache line fails, and a compile error means nothing runs.

How to reason it out
  1. Work out the readability graph: app reads mid and, through requires transitive, lib.
  2. For each referenced package, check whom lib exports it to.
  3. lib.api: everyone, so the Names call is fine.
  4. lib.impl: mid only, so the Cache reference is a compile-time error.

Exam tip: Reading a module and being exported to are separate tests; requires transitive never widens a qualified export.

Java Modules, Services and Module Imports (1Z0-831) — the lesson that teaches this.

Question 4Packaging and Deploying Java Code

Given:// money/module-info.java module money { exports money; } // money/money/Amount.java package money; public record Amount(long cents) { } // billing/module-info.java module billing { requires money; exports billing; } // billing/billing/Invoice.java package billing; import money.Amount; public class Invoice { public Amount total() { return new Amount(250); } } // app/module-info.java module app { requires billing; } // app/app/Main.java package app; import billing.Invoice; import money.Amount; public class Main { public static void main(String[] args) { Amount a = new Invoice().total(); System.out.println(a.cents()); } }Compiling app fails because it does not read module money. Which declaration of billing, with no change to app, lets the program compile and print 250?

Choose one.

  • a
    module billing { requires static money; exports billing; }

    requires static makes money optional at run time for billing; it passes no readability on to app, so app still cannot see money.Amount.

  • b
    module billing { requires money; exports billing; exports money; }

    A module can export only packages it contains. money belongs to module money, so javac rejects the directive in billing.

  • c
    module billing { requires transitive money; exports billing; } Correct

    requires transitive money gives every module that reads billing implied readability of money, so app can name money.Amount without its own requires money.

  • d
    module billing { requires money; exports billing; opens money; }

    opens refers only to packages in the declaring module, so javac merely warns that money is empty or does not exist in billing. opens also never grants compile-time access, so app still cannot see money.Amount.

The concept

requires transitive gives implied readability: any module that reads the declaring module also reads the transitively required module.

Why that’s the answer

billing's public API returns money.Amount, so callers of billing need to read money too. Adding transitive to billing's requires money makes app read money automatically. requires static passes nothing on. Exporting another module's package is a compile-time error, and opening it only draws a warning and never grants compile-time access, so neither helps app.

How to reason it out
  1. Find the type app cannot see: money.Amount, from module money.
  2. Note the constraint: app's declaration stays unchanged.
  3. Choose the directive that forwards readability to billing's readers: requires transitive.
  4. Reject exports/opens of a package billing does not contain.

Exam tip: When your API exposes another module's types, require that module transitively.

Java Modules, Services and Module Imports (1Z0-831) — the lesson that teaches this.

Question 5Packaging and Deploying Java Code

Given:// money/module-info.java module money { exports money; } // money/money/Amount.java package money; public record Amount(long cents) { } // billing/module-info.java module billing { requires money; exports billing; } // billing/billing/Invoice.java package billing; public class Invoice { public money.Amount total() { return new money.Amount(250); } } // app/module-info.java module app { requires billing; } // app/app/Main.java package app; public class Main { public static void main(String[] args) { var a = new billing.Invoice().total(); System.out.println(a.cents()); } }All modules are compiled together with javac --module-source-path, and the program is launched with java -p out -m app/app.Main. What is the result?

Choose one.

  • a
    It prints 250.

    Using var does not bypass readability. The call a.cents() is a member of money.Amount, and app does not read module money.

  • b
    It throws NoClassDefFoundError.

    money is on the module path and is resolved because billing requires it, so a run would find the class; the failure is earlier, at compile time.

  • c
    It throws IllegalAccessError.

    The readability problem is detected by javac when it checks the cents() call, so no class file for Main is produced.

  • d
    Compilation fails. Correct

    app reads billing but not money, because billing uses a plain requires money. javac reports that Amount.cents() is not accessible: package money is declared in module money, but module app does not read it.

The concept

A plain requires is not forwarded: readers of billing do not read money, even when billing's public methods return money types.

Why that’s the answer

Readability is not transitive by default. app requires billing; billing requires money without transitive. When app calls a.cents(), the member belongs to money.Amount, and javac checks that app reads the module of that type. It does not, so compilation fails. Making billing declare requires transitive money, or adding requires money to app, would fix it.

How to reason it out
  1. Trace app's readability: billing only.
  2. Identify the type of a: money.Amount, from module money.
  3. Calling a member of that type needs app to read money.
  4. A plain requires does not forward readability, so javac reports an error.

Exam tip: var hides a type name, not a module boundary: members of an unread module's types are still inaccessible.

Java Modules, Services and Module Imports (1Z0-831) — the lesson that teaches this.

Question 6Packaging and Deploying Java Code

Given these module declarations:// app/module-info.java module app { requires alpha; } // alpha/module-info.java module alpha { requires transitive beta; exports alpha.x; } // beta/module-info.java module beta { requires gamma; requires java.sql; exports beta.x; } // gamma/module-info.java module gamma { exports gamma.x; }Each named package contains a public class. Code in module app declares a local variable of one type. Which two types can that variable have for app to compile? (Select TWO.)

Choose TWO.

  • a
    gamma.x.G

    beta requires gamma without transitive, so readability of gamma stops at beta; app does not read gamma.

  • b
    alpha.x.A Correct

    app requires alpha, and alpha exports alpha.x, so the public class A is accessible.

  • c
    java.sql.Connection

    beta's requires java.sql is not transitive, so only beta reads java.sql. app has no path of transitive edges to it.

  • d
    beta.x.B Correct

    alpha requires transitive beta, so app reads beta through implied readability, and beta exports beta.x.

  • e
    alpha.internal.Impl

    app reads alpha, but alpha does not export alpha.internal, so its public class Impl is not accessible from app.

The concept

A module reads the modules it requires, plus every module reachable through a chain of requires transitive edges starting from those; it can then use only exported packages.

Why that’s the answer

Start from app: it requires alpha, so it reads alpha. alpha requires transitive beta, so app also reads beta. beta's own requires of gamma and java.sql are plain, so they are not passed on. Then check exports: alpha.x and beta.x are exported, alpha.internal is not. That leaves A and B.

How to reason it out
  1. List app's direct reads: alpha.
  2. Follow only transitive edges from there: alpha to beta.
  3. Stop at beta's plain requires of gamma and java.sql.
  4. From the readable modules, keep only types in exported packages.

Exam tip: Implied readability follows requires transitive edges only; one plain requires ends the chain.

Java Modules, Services and Module Imports (1Z0-831) — the lesson that teaches this.

What 1Z0-831 domain 7 tests, topic by topic

The official exam guide breaks Packaging and Deploying Java Code into 2 topics. The question bank follows the same split, so a weak topic shows up as a cluster of misses you can go back and read.

Published 1Z0-831 practice questions per topic in Packaging and Deploying Java Code
TopicWhat it coversQuestions
Modules, services and module import declarationsOfficial 1Z0-831 objective 7.1: "Define modules and expose module content, including that by reflection, declare module dependencies, define services, providers, and consumers, and use module import declarations."43
Compiling and running code, JARs, runtime images and migration to modulesOfficial 1Z0-831 objective 7.2: "Compile and run Java source code, including compact source files, instance main methods, and multi-file source-code programs; create modular and non-modular jars and runtime images; and implement migration to modules using unnamed and automatic modules."43
Total86

Revise Packaging and Deploying Java Code before you drill it

Java Modules, Services and Module Imports (1Z0-831)Questions on this objective are mostly multi-module code: several module-info.java files and a few classes, followed by 'What is the result?' or 'Which declaration makes it work?'. Expect to decide whether a reference compiles from readability, exports and public access together, to tell apart compile errors, boot-layer failures and run-time exceptions (NoClassDefFoundError, InaccessibleObjectException, ServiceConfigurationError, NoSuchElementException), and to pick which directives satisfy a stated access requirement. Service items test the uses/provides split, provider validity and ServiceLoader's lazy caching; module-import items test what import module covers, when it needs readability, and how clashing names resolve, including inside compact source files.Compiling and Running Java: Compact Source Files, JARs, jlink and Module Migration (1Z0-831)Objective 7.2 is examined mostly through exact commands and short programs: what a given java, javac, jar or jlink command line does, which of several commands works, or what a compact source file or a class with several main methods prints. Expect launcher error messages and exceptions (ClassNotFoundException, NoClassDefFoundError, FindException, ResolutionException, IllegalAccessError) as genuine answers alongside outputs, and multiple-answer items asking which two commands run a program. Distractors lean on near-miss details: an option placed after the file or JAR name, a class path that points inside the package tree, -m given a class name, a JAR on the class path rather than the module path, a file name that derives a different automatic module name, or a jlink run over a graph that still contains an automatic module. Migration items ask about ordering, what the unnamed and automatic modules can read, and why split packages fail.

Other 1Z0-831 domains

Domain 1: Handling Date, Time, Text, Numeric and Boolean Values11% of the exam · 105 questionsDomain 3: Applying Object-Oriented Principles in Java Programs18% of the exam · 175 questionsDomain 6: Processing Data Using Streams and Lambda Expressions9% of the exam · 86 questionsDomain 8: Implementing Multithreading for Concurrent Code Execution11% of the exam · 105 questionsDomain 9: Performing Input and Output Operations Using the Java I/O API11% of the exam · 105 questionsAll 1Z0-831 practice questionsMixed sessions across all 10 domains — the way the real exam interleaves them.

Packaging and Deploying Java Code: your questions

Packaging and Deploying Java Code is domain 7 of the 1Z0-831 exam guide and carries 9% of the scored content — the 5th-heaviest of the 10 domains. On a 50-question paper that works out to roughly 5 questions, though Oracle does not publish an exact per-domain count and individual exam forms vary.

Source

The domain weight and topic list on this page come from the official 1Z0-831 exam guide.