"Pause" does not work anymore

[d01010101]

Apache NetBeans version

Apache NetBeans 16

What happened

Did "Pause" actually ever go to the paused statement, as in case of other IDEs? I may be wrong, but I seem to recall that it was the case. Now it works just never, no matter which project. Pressing "Pause" stops the execution, enables the "Continue" button and the latter is the only visible effect. I still have no idea which code line or even thread has been paused.

How to reproduce

Just run the debugger and press "Pause". It may be an Ant single-thread project, a Maven project with multiple user threads, does not matter.

Did this work correctly in an earlier version?

No / Don't know

Operating System

Ubuntu 20.04

JDK

OpenJDK 64-Bit Server VM (build 14.0.1+7, mixed mode, sharing)

Apache NetBeans packaging

Apache NetBeans provided installer

Anything else

No response

Are you willing to submit a pull request?

No

Code of Conduct

Yes

[neilcsmith-net]

It sounds like you're expecting Pause to function like hitting a breakpoint? You can use the debugger tab to see all paused threads, where they're paused, and jump to the required code lines in each.

[d01010101]

Why it does not happen automatically if there is only one running thread within main and threads created by main?

[d01010101]

Or alternatively, if there is only one thread running the code of currently open projects?

[neilcsmith-net]

Personally, I don't see the benefit in doing this, and on only the simplest projects could it do anything useful. I'm also not sure it's a bug. Moving to feature request, but leaving open in case anyone thinks it's something worth pursuing.

[d01010101]

Can you justify your conclusion that the projects, which do not have most of the time multiple threads running at the same time the code which is currently open, are "only the simplest projects"?
This is my second bug report. In the case of the first one, I made a list of several arguments. Your argument was "I like it as it is now". I won't even attempt to try to convince you the second time.

[neilcsmith-net]

Yes, I can. Still, it's not about convincing me, it's about either putting in a pull request or convincing someone else that this is a feature worth looking. And on that basis, reopening.

[lkishalmi]

I do see that Pause , pauses all the threads, and you can examine the execution stack on each and every thread. Usually there are a handful of them. I would not want to inspect each and every one where it has stopped. It is also a pretty rare use case to do in a debugger (when hunting on a bad concurrency issue). So if anyone would like to contribute such a functionality, please consider that as optional.

[d01010101]

Did you even read what this issue was about? It was specifically about the case with a single thread running. Actually running, as in using CPU by going through the user code. Something deemed by your friend as "only a simplest project". Which would make Netbeans itself even more simple than "only a simplest project" because normally it takes 0% CPU.

[neilcsmith-net]

There's always more than a single thread in NetBeans itself, even when the IDE is using minimal CPU. It's even less clear to me what you think this should be doing now.

[d01010101]

I closed this issue seeing how the discussion is going. Ok, maybe they think it is useless, not a problem. Then you reopen it to talk about "any thread" in an answer to a message which said clearly that it is not about "any thread".

In IntelliJ, and most IDEs which I used, pausing navigates directly to a thread. But not to any thread. There is some logic to make it useful. I asked about a feature commonly implemented in other IDEs for user's convenience. See for example here https://www.youtube.com/watch?v=lAWnIP1S6UA&t=54s

[neilcsmith-net]

NetBeans does a similar thing as long as the thread you're interested in is made current. Above you linked running threads to CPU usage (in the context of NetBeans itself), but that doesn't correlate to the most logical or useful thing to do. It's not clear what you think is the logical thing to do!

Possibly we could make main current by default. Possibly we could ensure the relevant source file is open in the current thread when paused.

You might be better looking at this? https://netbeans.apache.org/kb/docs/java/debug-multithreaded.html#_suspending_threads

[d01010101]

I would just like to have a similar experience to what other IDEs do. Maybe I cannot explain it clearly for some reason. For example, because a running thread may mean either "not suspended" or actually running (R) on the system level. I used it in the second sense.

Imagine that there is a complex Spring application with dozens of threads marked as running in Debugger. But of those, most are in Unsafe.park and anyway, they are all almost all the time asleep. But then, some web service is called and a servlet thread starts to execute a lengthy single-thread service algorithm whose code belongs to a class of one of the projects currently open in the IDE. At the same time, some internal Spring service starts to do some internal housekeeping.

Then, Pause is hit. As it turns out, only two threads are in the running state, as in R in top. But only one of these - the servlet thread - runs code such that its call stack contains at least one method whose code belongs to a class being part of one of the currently open projects. Shortly, a code which can be directly opened in the editor.

As there is only one such thread and thus, there is no ambiguity, then apart from suspending all threads, the editor navigates to the suspended line in that one thread. Even web multi-user applications, when tested offline, may frequently have either none or a single thread type in question. Even more so, a test application of some mathematical code.

But if there were multiple such threads, NB could behave exactly as now, giving thus a hint to the user that there is an ambiguity. To make the hint even more clear, NB could select the Debugger tab in such a case, if one is already open.

That's how I would see it, but an actual NB developer might see additional possibilities and design it differently/better. But then, lack of such a feature is not critical and thus, there is probably a higher priority work, given the project's size.

[d01010101]

Alternatively, the whole method could be used only if there is no current thread and only to select one.

[d01010101]

But in an application with a pool of threads, is not the current thread eventually pointing to something random?