Overview
Domain 7 has two objectives. The first is about defining modules: writing module-info.java with requires, requires transitive, exports and opens directives, exposing packages for reflection, and building services from a service interface, provider modules and consumer modules wired together with provides, uses and ServiceLoader. The second is about the toolchain: compiling with javac, creating modular and non-modular jars, building custom runtime images with jlink, and migrating applications with unnamed and automatic modules.
Questions mix module-info syntax with command-line knowledge. You may be asked which directive lets a framework reflect on private members, which command lists module dependencies, or where an unnamed or automatic module fits in a migration plan.
How it's tested
Questions present one or more module-info.java files, a short command line, or a migration scenario. You choose the directive that fixes an access error, the command that produces a given result, or the module type a jar becomes. Read package names carefully, since a single mismatched package often decides the answer.
-
Fix the access error
Code fails because a package is not exported, not opened for reflection, or not readable, and you choose the module-info change that fixes it.
-
Wire a service
An interface, a provider and a consumer sit in separate modules, and you pick the provides, uses and ServiceLoader code that connects them.
-
Choose the tool or option
A task such as listing dependencies, building a trimmed runtime or describing a module is given, and you select jdeps, jlink, jar or java options.
A persistence framework must set private fields on entity classes in package com.app.model at runtime, but other modules should not compile against those classes. exports would make the public types usable at compile time, which is more than required and still blocks private access. Writing opens com.app.model to the framework module grants deep reflection at runtime only, which matches the requirement.
Objectives 2
Official objectives from the Oracle outline, in outline order.
7.1 Define modules and expose module content, including that by reflection, and declare module dependencies, define services, providers, and consumers.module-info.java directives, readability, exports versus opens, and service loading.
- What it means
- A module is a named set of packages described by module-info.java. It declares which modules it reads with requires, which packages it makes accessible with exports, and which it makes available for deep reflection with opens or by declaring an open module. Services decouple a consumer from implementations through an interface, provides and uses directives, and java.util.ServiceLoader.
- What to understand
- requires transitive makes a dependency readable by any module that reads yours, and requires static is needed at compile time but optional at runtime. Qualified forms such as exports pkg to mod.a limit access to named modules. Unexported packages are strongly encapsulated, even for public classes. Every module implicitly reads java.base. In a service setup, the service interface lives in an exported package, the provider module declares provides Interface with Impl and needs no export of its implementation package, and the consumer declares uses Interface and calls ServiceLoader.load(Interface.class), then iterates, streams or calls findFirst. A provider class needs a public no-argument constructor or a public static provider() method. Without uses, ServiceLoader throws ServiceConfigurationError at runtime.
- How it shows up
- Expect module-info fragments with one missing directive, and service scenarios where you pick the correct consumer code.
- Common confusion
- Thinking exports allows reflection on private members, or that the provider must export its implementation package.
7.2 Compile Java code, create modular and non-modular jars, runtime images, and implement migration to modules using unnamed and automatic modules.javac, jar, java, jdeps and jlink options, plus unnamed and automatic modules in migration.
- What it means
- Modular code is compiled with javac using the module path, packaged into jars that contain module-info.class, and launched with java --module-path and --module. jlink assembles a custom runtime image containing only the modules an application needs. Migration lets existing jars keep working as unnamed or automatic modules while code is gradually modularized.
- What to understand
- Key options: -p or --module-path, -m or --module with module/main.class, -d for output, and --module-source-path for multi-module compiles. java --list-modules lists observable modules, and --describe-module or -d shows one module's directives; jar --describe-module does the same for a jar. jdeps analyses dependencies, with --jdk-internals flagging internal API use. jlink takes --module-path, --add-modules and --output. A jar on the class path joins the unnamed module, which reads all modules and exports everything, but named modules cannot require it. A jar without module-info on the module path becomes an automatic module, named from the Automatic-Module-Name manifest entry or the filename, exporting all packages and reading all modules. Bottom-up migration modularizes libraries first, while top-down migration modularizes the application first and relies on automatic modules for its dependencies.
- How it shows up
- Expect questions on the name an automatic module receives, what the unnamed module can read, and jlink or jdeps options.
- Common confusion
- Believing a named module can require the unnamed module, or that automatic modules export only some packages.
High-yield concepts
The terms, rules and formulas this domain turns into questions most often.
-
requires transitive
Passes readability to downstream modules.
- Remember
- Use it when your exported API exposes another module's types.
- Tested as
- Readability questions.
- Trap
- Using plain requires and expecting callers to read the dependency.
-
exports versus opens
Compile and runtime access versus runtime deep reflection.
- Remember
- opens allows private member reflection; exports does not.
- Tested as
- Framework access scenarios.
- Trap
- Exporting a package to enable setAccessible on private fields.
-
open module
Opens every package for reflection.
- Remember
- Still requires explicit exports for compile-time access.
- Tested as
- Declaration choice questions.
- Trap
- Thinking it exports packages too.
-
Service consumer
Module that uses a service interface.
- Remember
- Declares uses and calls ServiceLoader.load.
- Tested as
- Service wiring questions.
- Trap
- Forgetting uses and getting ServiceConfigurationError.
-
Service provider
Module that supplies an implementation.
- Remember
- Declares provides Interface with Impl; no export needed.
- Tested as
- Service wiring questions.
- Trap
- Exporting the implementation package unnecessarily.
-
Unnamed module
Everything on the class path.
- Remember
- Reads all modules, but named modules cannot require it.
- Tested as
- Migration questions.
- Trap
- Trying to add requires for class path code.
-
Automatic module
Plain jar placed on the module path.
- Remember
- Exports all packages; name from manifest or filename.
- Tested as
- Migration and naming questions.
- Trap
- Expecting it to need a module-info file.
-
jlink
Builds a custom runtime image.
- Remember
- Needs --add-modules and --output.
- Tested as
- Deployment questions.
- Trap
- Confusing it with jar or jmod.
-
jdeps
Dependency analysis tool.
- Remember
- --jdk-internals reports internal API use.
- Tested as
- Migration planning questions.
- Trap
- Choosing java --describe-module for dependency scans.
-
java.base
The module every module reads implicitly.
- Remember
- No requires directive needed.
- Tested as
- Readability questions.
- Trap
- Adding requires java.base and thinking it is mandatory.
Side by side
Concepts candidates mix up, compared on the point that decides the answer.
Module types
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Named module | Jar or directory with module-info | Explicit requires and exports | Expecting it to read the class path |
| Automatic module | Plain jar on the module path | Exports everything and reads all modules | Assuming its name always matches the package |
| Unnamed module | All code on the class path | Reads everything; cannot be required by name | Writing requires for it |
Access directives
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| exports pkg | Public types usable at compile time and runtime | No private reflection | Using it for ORM private field access |
| exports pkg to mod | Qualified export to named modules | Others cannot see the package | Assuming all modules gain access |
| opens pkg | Deep reflection at runtime | No compile-time access | Expecting to compile against its types |
| requires transitive mod | Implied readability for dependants | Passes access down the chain | Using it where a plain requires suffices |
Exam traps
Each trap is an answer that looks right. Learn the clue that should change your mind.
-
Export the implementation
- What candidates pick
- Adds exports com.shop.impl to the provider so consumers can find it.
- Why it looks right
- Consumers seem to need the implementation class.
- Why it's wrong
- ServiceLoader instantiates providers through the provides directive, so the implementation package can stay encapsulated.
Clue to watch for A provides ... with directive already present.
-
exports enables reflection
- What candidates pick
- Fixes an InaccessibleObjectException with exports.
- Why it looks right
- Exports is the familiar access directive.
- Why it's wrong
- exports covers public types only; deep reflection on non-public members needs opens or an open module.
Clue to watch for A framework calling setAccessible on private fields.
-
Requiring the unnamed module
- What candidates pick
- Adds a requires clause naming a class path jar.
- Why it looks right
- Every dependency seems to need requires.
- Why it's wrong
- The unnamed module has no name, so named modules cannot require it; the jar must become an automatic module.
Clue to watch for A library on the class path used by modular code.
-
Automatic module naming
- What candidates pick
- Uses the full jar filename including version as the module name.
- Why it looks right
- The jar name is the only identifier visible.
- Why it's wrong
- Without Automatic-Module-Name, Java removes the version and .jar suffix and turns non-alphanumeric characters into dots.
Clue to watch for A jar named like commons-text-1.10.jar.
-
Missing uses works
- What candidates pick
- Assumes ServiceLoader finds providers without a uses directive.
- Why it looks right
- The provider module declares provides correctly.
- Why it's wrong
- A named consumer module must declare uses, or ServiceLoader throws ServiceConfigurationError at runtime.
Clue to watch for Consumer module-info without a uses line.
Answer framework
Use these steps when a question involves modules, services or deployment tools.
- Map every package to its module and decide whether the code is a named module, an automatic module on the module path, or in the unnamed module.
- Check readability: does the using module require the other module directly or through requires transitive, remembering that java.base is always read?
- Check accessibility: is the package exported for compile-time use, or opened when the question involves reflection on private or protected members?
- For services, confirm the interface package is exported, the provider declares provides with, and the consumer declares uses and calls ServiceLoader.
- For tool questions, match the task to the command: javac and jar to build, java options to run or describe, jdeps to analyse and jlink to create images.
Practice question
Want more like this? The 1Z0-830 practice test has questions for every domain.
Checklist
0 of 11
Tick each one you can do without notes. Your ticks stay in this browser.
Study strategy
Modules are hard to learn from reading alone, so build a three-module project by hand. Create an API module with a service interface, a provider module and a consumer module, compile them with javac --module-source-path, and run the consumer with java -p and -m. Remove the uses directive, then the exports in the API module, and read each failure so you can recognise them on the exam.
Next, practise the tools. Run java --list-modules and --describe-module, run jdeps on one of your jars and on a plain library jar, and create a runtime image with jlink. Check the size of the image and list its modules.
Finish with migration. Put a plain jar first on the class path and then on the module path, and observe the automatic module name that Java derives from the filename. Write a short table comparing named, automatic and unnamed modules, plus one for exports, opens and requires transitive. This is a small section, so two or three practical sessions should be enough.
FAQ
How much of 1Z0-830 is Domain 7, Packaging and Deploying Java Code?
Oracle publishes no weight for this section. With two objectives, we estimate about three questions, but each tends to need precise syntax knowledge.
Is JDBC still on the Java 21 exam?
Enthuware's comparison with the Java 17 exam reports that JDBC was removed from the 1Z0-830 objectives. Focus this section on modules and deployment tools.
Does a service provider need to export its package?
No. The provides directive registers the implementation with ServiceLoader, so the implementation package can stay encapsulated inside the provider module.
How is an automatic module named?
From the Automatic-Module-Name entry in the jar manifest if present. Otherwise Java derives it from the jar filename, dropping the version and replacing invalid characters with dots.
What is the difference between exports and opens?
exports gives access to public types at compile time and runtime. opens gives deep reflective access at runtime only, including private members.
Do I need to know jmod?
The objective names jars and runtime images. Know jlink well, and treat jmod files as an input format that jlink can consume.
Test your Domain 7 knowledge
You have reviewed module declarations, exports and opens, services, the java, jar, jdeps and jlink tools, and migration with unnamed and automatic modules. Check how precisely you recall the syntax.
Keep going
- Training Training Built on your Weak areas
- Practice test Questions by domain, with explanations
- Mock exam Full length, timed like the real exam
- Readiness test Find your weakest domain in minutes
- Cheat sheet Key terms and formulas on one page
- Ask the 1Z0-830 AI tutor Get any concept explained your way