[critical] Improve lambda breakpoints when using gradle build server

[gayanper]

When using gradle build server, the lambda method name tends to change on large file which I'm not sure of the reason which I have not looked into Java Language Spec on how lambda method names are computed.

What was observed is the method name has the format classMethodName$lambda$#. This cause method name mismatches due to the JDT method name and JDI method name is different.

[gayanper]

Jinbo Wang (@testforstephen) could we use the source location information of the method or something similar to narrow down the method to match signature instead of using the name ? Not using the name could resolve this issue.

[testforstephen]

gradle build server uses the javac to compile the code, which may use different rules to name the generated classes. Do you have a concrete use case to explain the issue further?

[github-actions]

Hi Gayan Perera (@gayanper), I'm an AI Support assistant here to help with your issue. While the team reviews your request, I wanted to provide some possible tips and documentation that might help you in the meantime.

• Track the existing feature request for lambda breakpoint support in the VS Code Java debugger:
  • “add support for lambda breakpoints” (covers entry breakpoints on generated lambda methods)
  • add support for lambda breakpoints vscode-java-debug#1160

• Currently there’s no workaround: JDT generates synthetic lambda method names (classMethodName$lambda$#) that don’t match what JDI exposes. You can upvote/comment on that issue or contribute a PR to align naming in the debug engine.

The team will respond to your issue shortly. I hope these suggestions are helpful in the meantime. If this comment helped you, please give it a 👍. If the suggestion was not helpful or incorrect, please give it a 👎. Your feedback helps us improve!