Netbeans has a tabbed window in the Output section called "Debugger Console". Is it possible to write a message to this window using Java? If so, how?
The messages you see in the debugger console are either
informations given by the debugger itself (breakpoint added, for example)
custom messages associated with a breakpoint
When you add a breakpoint to a line of code, the default behavior of the breakpoint is to suspend the thread that executed the line of code, and to print the text "Breakpoint hit at line {lineNumber} in class {className} by thread {threadName}.".
You can configure a breakpoint to print a custom text. This text will be output in the debugger console when it reaches the breakpoint. To do so, right click on a breakpoint, open the propoerties window, and enter your text in the field Print text.
A useful trick is to configure a breakpoint so that it does not block (suspend : no thread), and to enter a text. The effect is the same than adding println lines in your code, but the benefit is that you don't have to recompile the code, and it's easier to activate/deactivate these debugger logs (and it obviously does not stay on production code).
Note that, in the text of the breakpoint, you can use one of the special values {lineNumber}, {methodName}, {className} or {threadName}, and you can also evaluate some code with the syntax {=xxx}. Just replace xxx with a variable name, or a method call, or whatever.
OK for me it's in Output > Glassfish server 3+ Console
I wrote a simply System.out.println in my program and when the debugger arrive on this instructions the console diplay the result of my simply writing.
For others situation I don't know
Related
I've been tryna find an answer to this for a while but I'm a newbie with little hope left lol
In Java, I have two threads right now:
(main class) Thread A has a while loop listening to commands with Scanner.nextLine()
Thread B prints out "test" every second
When I start both threads, I can't properly type a command without it getting interrupted by Thread B's printing
Output:
test
test
commantest
dctest
ommandtest
test
test
How do I prevent this so I can type commands without any interruptions? I'm open to using ANSI Escape codes and JCurses (or any libraries reallyy) :)
Thanks!
There is no way of preventing this. The two threads are essentially using the same console, which for you looks messed up, but is in fact working exactly as it should. Note that both reading and writing should still work, despite the text on your console being garbled.
If you want to use the console for interacting with the user, you need to ensure that no other threads are using it at the same time. Depending on your use case you could for example send the other prints to a file, named pipe etc. Alternatively, if you are designing the console application with curses, you need to properly design it for multithreading (which, again, boils down to having a single thread dealing with the console, but in a way that keeps things on separate parts of the screen).
I have a global variable
static int debugNumber;
and a breakpoint with a condition
debugNumber > 1
with Suspend thread, Conditional and Suspend when 'true' checked. Currently, if I pause the execution of the program and hover over the declaration the value displayed is 2. Still, this breakpoint doesn't break.
As far as I can see on Google and here at SE debugNumber > 1 should be fine. What am I doing wrong?
Just so we're clear: That line means: If code execution gets to this line (the line with the breakpoint), then do what breakpoints usually do: Freeze the thread (or if you've configured things to be that way, and pause all other threads, which is not the default). However, a conditional breakpoint means: Before breaking as usual, check the condition. If the condition is false, then don't do anything.
A conditional breakpoint is going to break as often, or less often, than a normal breakpoint, never more often.
It sounds like what you want is to 'breakpoint' every line in the codebase that sets the debugNumber variable, if the value it is being set to is 2 or higher. If that's what you want, make a 'watch' on debugNumber and configure the watch to break execution.
If that's not what you wanted, then, well, you made no mistakes in what you describes, so then it's one of a billion things that could be wrong:
The line with your breakpoint was never hit.
The debugNumber was 1 or less when it hit your breakpoint.
You used 'run' to start your application and not 'debug' (there's pretty much no reason to ever 'run' anything, always pick 'debug')
The global 'disable all breakpoints' toggle within eclipse has been toggled off. It's (unless you changed things) on the toolbar: a larger 'breakpoint dot' (blueish circle) with a big slash through it. It's a toggle button. Is it pressed in?
Eclipse debugger has desynced. It will throw you a dialog if this happens, but one of the options in this dialog is 'ignore now and in the future' (It's a more succint text than that, but that's the gist of it). If you ever pressed that, it can desync. The debug view will tell you. This can happen if you change compiled code as eclipse runs, or change signatures in your source files and save the source file in the middle of a run.
Many many more things
I've been making a simple server that receives messages from multiple clients, then returns "hello" to the client. However, when I debug the program I run into issues, where some lines of code seem to freeze the debugger. This happens when I step through the program while debugging, and certain lines will cause me not to be able to continue stepping through the program. The "Continue", "Step Over", "Step Into", and "Step Out" can be clicked, but they don't advance the program.
Here is just one of the problem code blocks:
if(key.isReadable()){
String message = readFromChannel(key);
System.out.println(message); // Debugger always freezes here
sendToChannel(key, "hello");
}
I have never seen System.out.println() block, and I am thoroughly confused as to why this line of code seems to freeze the program.
Any help appreciated, as this is incredibly annoying.
I am using VS Code on MacOS Catalina, v1.14.1
The problem seemed to be caused by the expressions in the Watch tab. It works fine after I removed all the expressions from under the tab.
I have some multithreaded code and am trying to set up some breakpoints in Eclipse so I can do some debugging.
The breakpoint I want to set is in a class used by all of the threads. However, I only want the breakpoint to be hit when I am in the main thread. Is there a way to do this in Eclipse?
I have tried to use the 'conditional' breakpoint options but cannot get it to work.
Conditional breakpoint approach is good. The condition should looks like: Thread.currentThread().getName().equals("main").
If you want to set up a breakpoint for another thread you just have to change "main" to a thread-specific name, which can be provided via the Thread constructor.
You should be able to set up a conditional breakpoint by using a condition dependent on thread-local data. Two examples:
Thread.currentThread().getName(),
some value stored in a ThreadLocal.
There should be an item Filtering in the breakpoint properties dialog. There, you can limit the breakpoint to specific threads. But this only works when the program is already running since that dialog shows all threads from the running JVM.
I'm trying to debug my Client-Server UDP program to see what it is doing but when I get to the .receive() method (in either the client or the server code) the break point disappears and the step-into/step-over buttons turn gray. What I see next to the .receive() method call is a little white arrow that says "debug call stack" when I hover over it. What exactly is happening?
Has it something to do with the fact that it's a blocking call? If so how do I get past beyond this point?
Your call is blocked on that line, waiting for a read.
You can place another breakpoint right after that specific line. It will break after the receive() is done.
The block is probably native, so you can't really debug it. However, if you never get to the second breakpoint, you know that there is problem ;-)