JDK-8309399 outlines some inconsistencies in the JVMTI spec regarding OPAQUE_FRAME, and the need for spec clarification as to when OPAQUE_FRAME might be returned. JDI needs this clarification in order to determine when to throw OpaqueFrameException and NativeMethodException.

The main driving force behind this is the realization that for JVMTI PopFrames, ForceEarlyReturn, and SetLocalXXX, OPAQUE_FRAME does not always indicate a native method. This has always been the case, even before loom, and JDI has incorrectly always been throwing NativeMethodException for situations in which a native method is not the issue.

For popFrames(), forceEarlyReturn(), and setValue(), OpaqueFrameException has been reserved for virtual threads only, indicating the function cannot be performed on the virtual thread frame for a reason that is unique to virtual threads. However, since it is now realized that for platform threads OPAQUE_FRAME does not always mean there was a native method, and always throwing NativeMethodException is not appropriate, we should consider allowing OpaqueFrameException for platform threads when the failure cannot be due to a native method. This will help correct a long standing issues with JDI incorrectly throwing NativeMethodException, and provide more consistency between platform thread and virtual threads with regards to the throwing of OpaqueFrameException and NativeMethodException.

There is little compatibility risk with this change to sometimes (very rarely) throw OpaqueFrameException instead of NativeMethodException. As Alan noted:

"The popular IDEs have their own JDI implementation. IntelliJ IDEA ships with a fork of JDI, VS.Code and Eclipse use a fork. At this time, only NB uses our JDI implementation. This might help us get through the transition. It might be that their JDI maps the JDWP OPAQUE_FRAME to NativeMethodException so the debugger gets NativeMethodException today for non-native method reasons. It's not terrible but it means that the IDE vendor can change debugger + JDI at the same time if they want."

[UPDATE] No updates are needed for setValue() or getValue(). Given how JDI implements these APIs, it's not possible for calls to these JDI APIs to result in an underlying JVMTI/JDWP OPAQUE_FRAME due to a native frame. They require passing in a LocalVariable instance, which can only be obtained for a java local, which implies the frame cannot be native.