On Tue, 19 May 2026 12:36:38 GMT, Alan Bateman <[email protected]> wrote:
> > Yes I was avoiding writing a new AttachProvider. It would mean the > > precedence of filename and PID might be set by iteration order of the > > Providers. > > If someone renames a core file to 123 and there is a process 123 also running > then `jcmd 123 Thread.print` is ambiguous. How does putting both > implementation into one AttachProvider help this? It's not that this solves that very specific issue, it's that order of iterating the Providers is not (to me) the thing that should determine whether you get the file or the PID. That would seem to be outside anybody's control. We could create a HotSpotCoreFileOrMiniDumpProvider, which would get its chance to open a (id, env) pair. But then I can't say if that is before or after the exising PID attempt, and whether that will be the same for everybody, or will change. So HotSpotAttachProvider being given the vmid and the env, and it saying if it wants to open a file or a PID, makes sense to me. These clashes are uncommon, and you can generally rename a core file, but am trying to avoid introducing such a surprise. Like leaving the existing attach(id) method as not opening core files, that avoids a surprising change in behaviour if you have numeric files around. We can make changes in jcmd that use the attach(id, env) and prefer a core, or not, but an existing app that does attach(id) might suddenly fail when a numeric core file is present. ------------- PR Comment: https://git.openjdk.org/jdk/pull/31011#issuecomment-4488293247
