On Tue, 11 Nov 2025 12:37:59 GMT, Erik Gahlin <[email protected]> wrote:
> I can see the argument for not having the user's method as the top frame. A > user may get a quick hint (instead of looking at the line number) if they see > something like setInt(...), but this doesn’t work as well with tooling when > you want to group stack traces by top frame, for example in a tree view. You > typically want to see the application frame and then expand the nodes. If > setInt, setFloat, setLong, etc. appear as the top nodes, users have to click > and expand every setter, instead of seeing an aggregated list directly of > packages, classes, or methods where finals are modified. @egahlin and I discussed this and agreed to have the top-frame of the stack trace recorded with the event be the caller's method. This allows the stack filter include j.l.r.Field with listing method names. We might revisit this later to add further fields to the event to indicate an unreflect op and/or the field type. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25115#issuecomment-3518032863
