Hello Pavel,
> 1. It seems that jdeps ignores the "Class-Path" in the manifest when
analysing a JAR file. If so, it could be useful to state it explicitly
to reduce the risk of incorrectly analysing a fat jar.
A fat/uber JAR file is one that packages its dependencies (as JAR files)
within itself. The "Class-Path" attribute of such fat JAR cannot point
to those dependency JAR files that it packages within itself. Until
recently it wasn't clarified in the documentation. A recent update to
https://docs.oracle.com/javase/tutorial/deployment/jar/downman.html
clarifies this part. Specifically:
> Note: The Class-Path manifest attribute value doesn't refer to JAR
files or directories within the application JAR file. To load classes
and resources from JAR files within a JAR file, you must write custom
code. For example, if MyJar.jar contains another JAR file called
MyNested.jar, you cannot use the Class-Path attribute in MyJar.jar's
manifest to load classes in MyNested.jar.
> 3. In many contexts people use "dependence" and "dependency"
interchangeably, but I know that for modules those are deliberately
distinct. I might be wrong but I think the man page uses these two
incorrectly in a couple of places.
A similar issue has been brought up in context of jlink previously
https://bugs.openjdk.org/browse/JDK-8337422.
> 4. Also consider this patch to tag along with any possible
clarifications:
That patch seems to address some genuine issues in the man page text. I
think it would be worth to file a JBS issue just for that.
-Jaikiran
On 21/07/26 8:22 pm, Pavel Rappo wrote:
Resending my email that somehow got not delivered within 24 hours.
---------- Forwarded message ---------
From: Pavel Rappo <[email protected]>
Date: Mon 20 Jul 2026 at 15:11
Subject: Consider clarifying jdeps man page
To: core-libs-dev <[email protected]>
1. It seems that jdeps ignores the "Class-Path" in the manifest when
analysing a JAR file. If so, it could be useful to state it explicitly
to reduce the risk of incorrectly analysing a fat jar.
2. Could this option be clarified rather than merely repeated in prose?
--ignore-missing-deps
Ignore missing dependences.
3. In many contexts people use "dependence" and "dependency"
interchangeably, but I know that for modules those are deliberately
distinct. I might be wrong but I think the man page uses these two
incorrectly in a couple of places.
4. Also consider this patch to tag along with any possible clarifications:
diff --git a/src/jdk.jdeps/share/man/jdeps.md
b/src/jdk.jdeps/share/man/jdeps.md
index 52c2d4bffe4..3c23607524e 100644
--- a/src/jdk.jdeps/share/man/jdeps.md
+++ b/src/jdk.jdeps/share/man/jdeps.md
@@ -65,7 +65,7 @@ ## Possible Options
`-dotoutput` *dir* or `--dot-output` *dir*
: Specifies the destination directory for DOT file output. If this
option is
- specified, then the `jdeps`command generates one `.dot` file for each
+ specified, then the `jdeps` command generates one `.dot` file for each
analyzed archive named `archive-file-name.dot` that lists the
dependencies,
and also a summary file named `summary.dot` that lists the dependencies
among the archive files.
@@ -119,7 +119,7 @@ ## Possible Options
should be an integer \>=9 or base.
`-q` or `-quiet`
-: Doesn't show missing dependencies from `-generate-module-info` output.
+: Doesn't show missing dependencies from `--generate-module-info` output.
`-version` or `--version`
: Prints version information.
@@ -143,7 +143,7 @@ ## Module Dependence Analysis Options
`--check` *module-name* \[`,` *module-name*...\]
: Analyzes the dependence of the specified modules. It prints the module
descriptor, the resulting module dependences after analysis and the
graph
- after transition reduction. It also identifies any unused qualified
+ after transitive reduction. It also identifies any unused qualified
exports.
`--list-deps`
@@ -220,7 +220,7 @@ ## Options to Filter Classes to be Analyzed
`-I` or `--inverse`
: Analyzes the dependences per other given options and then finds all
- artifacts that directly and indirectly depend on the matching nodes.
This
+ artifacts that directly or indirectly depend on the matching nodes.
This
is equivalent to the inverse of the compile-time view analysis and the
print dependency summary. This option must be used with the
`--require`,
`--package`, or `--regex` options.
-Pavel
