Thanks for the feature @danthe1st, looks great on feature wise

Would it be possible to change highlight color for dark theme ? its bit hard to read

This pull request changes some projects for the first time in this development cycle.
Therefore the following files need a version increment:

org.eclipse.jdt.debug/META-INF/MANIFEST.MF

An additional commit containing all the necessary changes was pushed to the top of this PR's branch. To obtain these changes (for example if you want to push more changes) either fetch from your fork or apply the git patch.

From 0fc0c7499e1927da534bae46cee3001370717b67 Mon Sep 17 00:00:00 2001
From: Eclipse JDT Bot <jdt-bot@eclipse.org>
Date: Thu, 1 Jan 2026 05:20:08 +0000
Subject: [PATCH] Version bump(s) for 4.39 stream


diff --git a/org.eclipse.jdt.debug/META-INF/MANIFEST.MF b/org.eclipse.jdt.debug/META-INF/MANIFEST.MF
index 9afbed70f..bef1c1bbb 100644
--- a/org.eclipse.jdt.debug/META-INF/MANIFEST.MF
+++ b/org.eclipse.jdt.debug/META-INF/MANIFEST.MF
@@ -2,7 +2,7 @@ Manifest-Version: 1.0
 Bundle-ManifestVersion: 2
 Bundle-Name: %pluginName
 Bundle-SymbolicName: org.eclipse.jdt.debug; singleton:=true
-Bundle-Version: 3.25.0.qualifier
+Bundle-Version: 3.25.100.qualifier
 Bundle-ClassPath: jdimodel.jar
 Bundle-Activator: org.eclipse.jdt.internal.debug.core.JDIDebugPlugin
 Bundle-Vendor: %providerName
-- 
2.52.0

Further information are available in Common Build Issues - Missing version increments.

@SougandhS I updated this to use the current instruction pointer background color (see the updated screenshots).

Do you know whether there is a way to detect when the stack current stack frame is no longer there/when the highlighting should be removed (e.g. when resuming or stepping into a different file)?

@SougandhS I updated this to use the current instruction pointer background color (see the updated screenshots).

Thanks, much better now

Do you know whether there is a way to detect when the stack current stack frame is no longer there/when the highlighting should be removed (e.g. when resuming or stepping into a different file)?

You can achieve this by registering an IDebugContextListener and check that stackframe's status accordingly

@SougandhS Hi. Now that I was able to write a test for this as well, I think eclipse-jdt/eclipse.jdt.ui#2708 and this are ready for review.

Note that this won't be able to build successfully without eclipse-jdt/eclipse.jdt.ui#2708.
Also, as you probably see, I am not that experienced with the tests here ;).

I implemented some of the suppressed Copilot changes I consider to make sense but didn't implement the change in the review comment as this isn't really code I added.

Regarding the information about this being a prototype: I forgot to remove that from the PR description (done now).

Hi @danthe1st, Can you test the basic stepping with these 2 options enabled

Because those instructions are in the same line in the source file, they are skipped with and without statement stepping.

If I use a custom source file, it can make a difference.

But I noticed some other issues with a custom source file:

I'll have to take a look at that.

Nevermind, the issue was because I still had the class file open when I replaced the JAR so the content of the editor didn't match the code executed.

Code:

package dep;

public class Dep {
	public void a() {
		b();
	}
	void b(){
		print(
				c(),
				"",
				d(),
				"---"
		);
	}
	
	String c() {
		return "c";
	}
	String d() {
		return "d";
	}
	void print(Object... args) {
		for(Object o : args) {
			System.out.println(o);
		}
	}
}

I think #812 went in the wrong direction and this PR follows with more code.

With the addition of LambdaStackFrameSourceDisplayAdapter, every time I do debug steps inside lambda code, there is a source lookup call in the UI thread: SourceLookupFacility.lookup()

With this PR adding on top, a source lookup is done on every debug step - in the UI thread.

Normally the chain is: SourceLookupFacility.displaySource() -> SourceLookupJob (non-UI) -> SourceDisplayJob (UI) -> SourceLookupFacility.display() (opens editors, selects correct code)

The goal here must have been to not block the UI thread with source lookups - highlighting the current stack frame in the editor is secondary to smooth UI experience. I can imagine the source lookup causing noticeable mini-freezes in big workspaces (the effect would be tickets like eclipse-platform/eclipse.platform#2615).

Since the source lookup and display chain is skipped, custom code is added in LambdaStackFrameSourceDisplayAdapter and was added in this PR. Such code then needs to duplicate preference handling and such (missing in LambdaStackFrameSourceDisplayAdapter but added in this PR).

@SougandhS IMO we need to clean this up, this PR is a good opportunity to do so - since even more intricate code must run once the editor is opened. I need to think on how we want to operate on the editor (given the stack frame), once its opened in SourceLookupFacility.display()... it would be great if you can suggest ideas. Maybe we are in the wrong adapter code, I'm not sure. Maybe we need something new. Maybe this: org.eclipse.debug.ui.IDebugEditorPresentation.addAnnotations(IEditorPart, IStackFrame)

	/**
	 * Positions and adds annotations to the given editor for the specified
	 * stack frame and returns whether any annotations were added. When
	 * <code>true</code> is returned, a call will be made to remove annotations
	 * when the source selection is cleared for the stack frame. When
	 * <code>false</code> is returned, the debugger will position and add
	 * standard annotations to the editor, and a corresponding call to remove
	 * annotations will not be made. This method is called when the debugger is
	 * has opened an editor to display source for the given stack frame.
	 *
	 * @param editorPart the editor the debugger has opened
	 * @param frame the stack frame for which the debugger is displaying
	 *  source
	 * @return <code>true</code> if annotations were added to the given editor part <code>false</code> otherwise
	 */
	boolean addAnnotations(IEditorPart editorPart, IStackFrame frame);

Snippet where source lookups are called on every step inside lambda:

	public static void main(String[] args) {
		int n = 3;
		int m = 20;
		Runnable r = () -> {
		for (int i = 0; i < n; ++i) {
			String l = "0".repeat(m);
			System.out.println(l);
		}
		};
		r.run();
	}

Once within the Runnable.run() body the lambda adapter runs its lookups.

I think #812 went in the wrong direction and this PR follows with more code.

@SougandhS IMO we need to clean this up, this PR is a good opportunity to do so - since even more intricate code must run once the editor is opened. I need to think on how we want to operate on the editor (given the stack frame), once its opened in SourceLookupFacility.display()... it would be great if you can suggest ideas. Maybe we are in the wrong adapter code, I'm not sure. Maybe we need something new. Maybe this: org.eclipse.debug.ui.IDebugEditorPresentation.addAnnotations(IEditorPart, IStackFrame)

Handled this in a new PR 👍

Handled this in a new PR 👍

I guess my PR should wait for that and I can update it once that's merged. Hence, I'm marking this as a draft for now.

@danthe1st please hold off rebasing, I'll try to adjust the test and I'll rebase in the process.

please hold off rebasing, I'll try to adjust the test and I'll rebase in the process.

Sorry, I didn't see that until now/I only saw the notification of the other PR being merged

I've adjusted two things in the PR:

1. The tests no longer open the editor manually, IMO we want to test what the user will be seeing. This slows the tests somewhat, also due to creating the test project for each test. testDisplaySourceWithClassFileEditorHighlightsLine also compiles with debug line information, since otherwise Eclipse doesn't allow to create the line breakpoint.
2. The editor unhighlight code now runs in a UI job - I'm not sure the code belongs in the debug event notification thread, so I've moved it. Listener registration and deregistration is also done in the UI thread so no need to synchronize it anymore. @danthe1st please test if the unhighlight and listener deregistration works as expected, if this is not covered by the tests.

When I run the tests with coverage, JavaStackFrameEditorPresenter.removeAnnotations(IEditorPart, IThread) is not covered. I'm not sure when this code runs, we'll have to check. I'm also not sure if this code needs to unregister the listener.

I've also adjusted the test to have to run only a small part of the code in the UI thread, so I've removed the UI debug suite.

I'm not sure when this code runs, we'll have to check. I'm also not sure if this code needs to unregister the listener.

When I tested it, it didn't seem to be executed at all.

When I tested it, it didn't seem to be executed at all.

I'll try to find where its called.

One more thing to check:

What happens if I close the class editor and another editor is opened when stepping? Will the unhighlighting work? Or if debugging multiple programs. Or the same program with multiple class files.

For the listener probably with different workbench windows we will have a problem too. Likely we need a list of registered listeners / highlighted editors, or some other mechanism that doesn't rely on fields (e.g. a task queue for the clean-up job). For the editors we likely must check if the editor is still opened before removing highlights.

I'm also not 100% sure what the life-cycle of org.eclipse.jdt.internal.debug.ui.JDIModelPresentation is.

Probably this is another case where we should check what platform debug is doing to remove line highlighting when the debug launch is terminated.

And it will be good to have a test for terminating the debug launch and checking that the active class editor has no highlight.

What happens if I close the class editor and another editor is opened when stepping? Will the unhighlighting work? Or if debugging multiple programs. Or the same program with multiple class files.

When I tested with what I tried yesterday (a listener that was registered using the IWorkbenchWindow of the editor), unhighlighting worked. I can test it again later.

For the listener probably with different workbench windows we will have a problem too.

I can check that as well.

@danthe1st if you have time, can you first check where the Java editor line highlight is removed when terminating a Java debug launch? And what the call stacks are to get to there?

If addAnnotations returns true, removeAnnotations will be called when the instruction pointer doesn't need to be shown any more (this includes the launch being terminated). Both methods are called in a UI thread. I will update my PR accordingly.

I now used removeAnnotations for the unhighlighting and I added an assertion that ensures this is actually done after termination. However, I think I noticed an NPE in that class so I'll fix that as well.