using method name to find unqualified Stacktraces in Java Stack Trace

[SougandhS]

Using method name to find unqualified Stacktraces
Fix for - #115

What it does

Resolves the ambiguity in results generated when fully qualified class name is not provided in java stack trace console

How to test

Author checklist

• I have thoroughly tested my changes
• The change is following the coding conventions
• I have signed the Eclipse Contributor Agreement (ECA)

[SougandhS]

Hi @jukzi
Made changes for enhancement you proposed -> 115 .
Could you please review this PR ?

[jukzi]

generally looks good and has a Junit test :-) i plan to actually test the PR later

[jukzi]

i tested the change with
Project.writeDescription(int) line: 1402 in platform workspace and ended up in exception:

java.lang.ClassCastException: class org.eclipse.jdt.internal.core.BinaryType cannot be cast to class org.eclipse.jdt.internal.core.SourceType (org.eclipse.jdt.internal.core.BinaryType and org.eclipse.jdt.internal.core.SourceType are in unnamed module of loader org.eclipse.osgi.internal.loader.EquinoxClassLoader @35f7b857)
	at org.eclipse.jdt.internal.debug.ui.console.JavaStackTraceHyperlink$3.runInUIThread(JavaStackTraceHyperlink.java:215)
	at org.eclipse.ui.progress.UIJob.lambda$0(UIJob.java:148)

[jukzi]

no exceptions, but feels like it still has issues to find methods with two parameters. here are some examples:
Realm.runWithDefault(Realm, Runnable) line: 339
PlatformUI.createAndRunWorkbench(Display, WorkbenchAdvisor) line: 173

should have found org.eclipse.core.databinding.observable.Realm

DirectMethodHandleAccessor.invokeImpl(Object, Object[]) line: 155

Method.invoke(Object, Object...) line: 580

Main.invokeFramework(String[], URL[]) line: 668

[jukzi]

And i get StringIndexOutOfBoundsException on parameterized types:
LinkedList<E>(Object).wait() line: 339

java.lang.StringIndexOutOfBoundsException: Range [22, 21) out of bounds for length 38
	at java.base/jdk.internal.util.Preconditions$1.apply(Preconditions.java:55)
	at java.base/jdk.internal.util.Preconditions$1.apply(Preconditions.java:52)
	at java.base/jdk.internal.util.Preconditions$4.apply(Preconditions.java:213)
	at java.base/jdk.internal.util.Preconditions$4.apply(Preconditions.java:210)
	at java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:98)
	at java.base/jdk.internal.util.Preconditions.outOfBoundsCheckFromToIndex(Preconditions.java:112)
	at java.base/jdk.internal.util.Preconditions.checkFromToIndex(Preconditions.java:349)
	at java.base/java.lang.String.checkBoundsBeginEnd(String.java:4865)
	at java.base/java.lang.String.substring(String.java:2834)
	at org.eclipse.jdt.internal.debug.ui.console.JavaStackTraceHyperlink$3.runInUIThread(JavaStackTraceHyperlink.java:211)

[jukzi]

bonus: Nested Class (with $) are also not found:
AbstractQueuedSynchronizer$ConditionNode.block() line: 519

[SougandhS]

@jukzi thanks for the additional cases, will make changes and fix the issues.

[SougandhS]

Hi @jukzi ,
Made changes for handling additional scenarios. (included in the test cases)

• ignore 3 test case failure as it is from java 23 changes.

[jukzi]

Please figure out why the Build fails InstanceMainMethodsTests - may be related to the Java23 merge @jarthana

[jukzi]

The tests are also failing on master:
https://ci.eclipse.org/jdt/job/eclipse.jdt.debug-github/job/master/119/
If failing tests are unrelated please create an Issue for it and then we could ignore them for the current PR

[SougandhS]

The tests are also failing on master: https://ci.eclipse.org/jdt/job/eclipse.jdt.debug-github/job/master/119/ If failing tests are unrelated please create an Issue for it and then we could ignore them for the current PR

these tests are unrelated to the current changes, will raise issue for those now

[SougandhS]

@jukzi those 3 tests are now passing for all builds now.
shall we close Issue ?

[jukzi]

I have tested and it works like a charm. Very good improvement. thanks.
Found two other stacktraces that do not work yet(wrong linenumber jumped to):

ScheduledThreadPoolExecutor(ThreadPoolExecutor).runWorker(ThreadPoolExecutor$Worker) line: 1130	
ThreadPoolExecutor.runWorker(ThreadPoolExecutor$Worker) line: 1130

Please let me know if you want to fix those too in this PR. Otherwise we can also submit the current state as it already is an improvement as is.

[SougandhS]

I have tested and it works like a charm. Very good improvement. thanks. Found two other stacktraces that do not work yet(wrong linenumber jumped to):

ScheduledThreadPoolExecutor(ThreadPoolExecutor).runWorker(ThreadPoolExecutor$Worker) line: 1130	
ThreadPoolExecutor.runWorker(ThreadPoolExecutor$Worker) line: 1130

Please let me know if you want to fix those too in this PR. Otherwise we can also submit the current state as it already is an improvement as is.

hi @jukzi ,fixed those and added additional tests for that in the latest commit.

[SougandhS]

@jukzi all commits have squashed into one now. (includes additional case's fix)

[jukzi]

@SougandhS thanks! let's try it in real :-)

[SougandhS]

Thank you @jukzi :)