All CLA requirements met.

Seems like we need to move to Java 17 JDK for building @testforstephen

Seems like we need to move to Java 17 JDK for building @testforstephen

Yes, I have another PR #420 to use JDK 17 as build jdk.

checkstyle failed, you can run ./mvnw checkstyle:check to check it.

Error:  src/main/java/com/microsoft/java/debug/core/adapter/IBreakpointManager.java:[85] (regexp) RegexpSingleline: Line has trailing spaces.
Error:  src/main/java/com/microsoft/java/debug/core/adapter/IBreakpointManager.java:[86] (javadoc) NonEmptyAtclauseDescription: At-clause should have a non-empty description.

@gayanper Thanks for bringing the support for function breakpoints, it's a good improvement.

I tried this PR with VS Code client and it basically works. I just have some concerns about the ease of use.

Currently, the user must add a FQN#methodName to enable a function breakpoint, which is not transparent to user, and it is also not user-friendly to enter such a long name in the text input box.

It is OK to keep the current design. But it would be a nice addition if we could also allow adding function breakpoints at the code where the function is declared.

For example, when adding a breakpoint at line 6, then the debugger is able to auto register it as a function breakpoint.

@gayanper Thanks for bringing the support for function breakpoints, it's a good improvement.

I tried this PR with VS Code client and it basically works. I just have some concerns about the ease of use.

Currently, the user must add a FQN#methodName to enable a function breakpoint, which is not transparent to user, and it is also not user-friendly to enter such a long name in the text input box.

It is OK to keep the current design. But it would be a nice addition if we could also allow adding function breakpoints at the code where the function is declared.

For example, when adding a breakpoint at line 6, then the debugger is able to auto register it as a function breakpoint.

Thats a good suggestion, I can actually improve this PR to support that.

@gayanper In the current version, it seems that method breakpoints don't work if I add two method breakpoints for the same class. If this issue is resolved, I am willing to merge this PR first. We can use a new PR to support enabling method breakpoints at the declaration positions.

WDYT?

Sure @testforstephen I can try to finish this in coming weekend

@gayanper Based on your commit, I sumbited a new PR #424 to address the issues with function breakpoint.

Thats good @testforstephen. Last week i got busy with some work and fixing few eclipse features. Shall we close this PR since you have the new PR with these changes ?

@gayanper yes, we can close this PR, thanks for the contribution.