On Fri, 19 Jun 2026 13:13:29 GMT, Severin Gehwolf <[email protected]> wrote:
> I'm not sure why we are trying to fix this in the > `StripNativeDebugSymbolsPlugin`. That plugin is useful to process a binary > which includes debug symbols in the binary itself. In a way, you are > re-implementing what the `--exclude-files` plugin already does. I think both ways are possible. One could argue, that "external" debug symbols files are also debug symbols like the internalized ones and so, stripping could mean filtering out those external files when they are present. I think syntactically, when the jlink option `--strip-debug` is used, it fits perfectly well to do this file filtering. Now, whether it is done through a chained call to the `--exclude-files` plugin or the `--strip-native-debug-symbols` plugin would be an implementation detail. > I thought the consensus on the bug was to use `exclude-files` in `jpackage`. > A CSR would need to be filed for an update to that filter. Was it consensus? Hm, I actually just now understood your comment at the bug which already suggests that you are against using the strip-debug-symbols plugin for this purpose... 😄 But, maybe it would be an idea to handle the file filtering in [DefaultStripDebugPlugin.java](https://github.com/openjdk/jdk/blob/master/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/DefaultStripDebugPlugin.java) by calling the `--exclude-files` plugin there and then also filter out debug files on Windows and MacOS. A CSR could be done to be on the safe side to postulate the modified jlink `--strip-debug` behavior but one could also argue that it is just a bug to be fixed. I'd be easy on that one. ------------- PR Comment: https://git.openjdk.org/jdk/pull/31534#issuecomment-4752014056
