On Fri, 12 Jun 2026 09:54:55 GMT, Dusan Balek <[email protected]> wrote:
> When used with the `--system` option to target a different modular JDK image, > `JdepsTask` keeps both `lib/jrt-fs.jar` and `lib/modules` open after it > completes. This is the `jdeps` counterpart of the issue previously seen with > `JavacTask` in JDK-8357249. > > For an alternate `java.home`, `JdepsConfiguration.SystemModuleFinder` creates > a new `jrt:/` file system using the target image. That file system and the > URL class loader used by its provider, are not closed when the jdeps > configuration is closed. > > The proposal is to modify `JdepsConfiguration.close()` to also close the > associated `SystemModuleFinder`, ensuring that these resources are released > after the task finishes. > > --------- > - [x] I confirm that I make this contribution in accordance with the [OpenJDK > Interim AI Policy](https://openjdk.org/legal/ai). src/jdk.jdeps/share/classes/com/sun/tools/jdeps/JdepsConfiguration.java line 287: > 285: for (Module module : nameToModule.values()) > 286: module.close(); > 287: system.close(); Ideally each close should be wrapped in try-catch but I guess it's okay to leave as is src/jdk.jdeps/share/classes/com/sun/tools/jdeps/JdepsConfiguration.java line 444: > 442: }); > 443: if (!list.isEmpty()) { > 444: IOException ex = new IOException(); Suggestion: IOException ex = list.removeFirst(); I think that's how suppression mechanism usually works. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/31498#discussion_r3403593687 PR Review Comment: https://git.openjdk.org/jdk/pull/31498#discussion_r3403594027
