On Sun, 18 Jan 2026 09:57:35 GMT, Yasumasa Suenaga <[email protected]> wrote:
> > Are you 100% sure that AttachNotSupportedException make sense to throw in > > this configuration? > > Yes. We don't know whether target process provides a compatible > `AttachProvider` if Attach API could not access `/tmp` of target process. > Target process might not be Java. So I think it makes sence to throw > `AttachNotSupportedException` with the cause. The user get a hint from > "Caused by" to check why Attach API failed. This is how we specified AttachNotSupportedException is specified: "Thrown by VirtualMachine.attach when attempting to attach to a Java virtual machine for which a compatible AttachProvider does not exist. It is also thrown by AttachProvider.attachVirtualMachine if the provider attempts to attach to a Java virtual machine with which it not compatible." When we introduced the attach API then the intention was to allow for other provider implementations so that the API could be used to attach to non-HotSpot VM. This is why VirtualMachine.attach iterates through the providers and attempts to attach each installed provider. Looking at it now, the JDK only includes one provider and it rare-to-never to have additional providers on the class path. In addition, it turns out to be "hard to impossible" for the HotSpot provider to distinguish non-HotSpot VM processes from environment/configuration/setup issues. I think it's a good time to re-visit this, maybe it is time to drop the throwing of AttachNotSupportedException as it's not helpful? In your example, the attach is failing and would be a lot clearer if it threw IOException (AccessDeniedException is an IOException) rather AttachNotSupportedException with the IOException as the cause. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28867#issuecomment-3765371426
