Develop Reference

During debugging, how to break execution after a specific line

I'm debugging a program and I have this line:
if (compareToName.equals(className)) {
Set<String> properties =
reflections.getResources(Pattern.compile(".*\\.properties"));
}
I have a breakpoint in the line that starts with Set<String>...
I want to know the value of properties after the execution of the line, but when I step over the line I'm over the block so the properties variable is not available in the variables window.

You're not going to get the value immediately after you step over that assignment because the value doesn't exist outside of the if statement. IntelliJ's debugger is still bound by the same rules of scope and variable lifetimes as other Java programs.
While I'm leery of this particular code snippet, getting the value isn't hard to do while in debug mode.
Alt+Left Click while hovering over a particular snippet (in this case, you'd hover over the dot to the right of the reflections bit.
Highlight the expression, then select "Evaluate Expression" (using the little calculator icon in the debug window). By default it will prepopulate that field with anything that is highlighted so that you can execute an evaluation of it.

Press Alt-F7 and enter the code you want to execute.
In your example:
reflections.getResources(Pattern.compile(".*\\.properties"));
you will see the result.

Debugging console input using NetBeans

Is there a way in NetBeans that while you are debugging a Java program to modify or check the value that a function or variable returns. The same way you can use the console in Matlab.
I'm not speaking about the usual debugging tools variable windows etc.
Example I want to break at a method in car class and input
>car.getMileage()
and get..
>car.getMileage()
>2500
or
>car.setMileage(100)
>car.getMileage()
>100

In Netbeans there is a tab under your source code window (there by default I think) called Variables. In that window you can edit the Value field of any variable that is in scope while suspended at a breakpoint. This value should update for the java application as you change it in real time. You can invoke methods the same way, by adding a watch. Like say you had a static method getInt(); which returns some value. Just make a watch for getInt(), and the Value column will show you the return value. So for your example, make a watch for car.setMileage(100) after your breakpoint is hit. The value column will likely be 'void'. Then make another watch for car.getMileage(). 100 should be returned.

Use an IDE such as Eclipse. You can set breakpoints, set statements and execute them. This is a feature of most modern IDEs actually.
More info on the display view can be found here : http://help.eclipse.org/helios/index.jsp?topic=/org.eclipse.jdt.doc.user/reference/views/debug/ref-debug_view.htm
For a nice overview of the debugging features of Eclipse, check out this post : http://www.cavdar.net/2008/09/13/5-tips-for-debugging-java-code-in-eclipse/

Inspect function of eclipse tricks me like a dummy, why does it seem to be that tricky while debugging?

Eclipse is awesome for writing java programs but today I find that it's awesome to trick new coders like me. #_#
I write a snippet as following,
public static void main(String[] args) {
for(int i=0;i<3;i++){
System.out.println("i = " + i);
}
}
then I add a breakpoint at the line of "System.out.print....", click "Debug" button, eclipse goes to the "Debug" perspective and the line of breakpoint is highlighted, then I move the cursor over variable "i", its value is "0" as expected.
And then, I select the "i++" and click "Inspect"(or press "Ctrl+Shift+I") once, I move the cursor over variable "i", its value changed to "1". I repeat "Inspect" again, the value of i changed to "2"......(its value will add by 1 every time I clicked the "Inspect")!!
Why does this happend!? I ONLY want to watch the value of "i" for debug propuse, DO NOT want to really change its value until I step into next statement. I think that "Inspect", as well as "Display" are only for viewing the variable/expression, they should not impact the value, but in this case, it doesn't work as I expect to.
Could anyone tell me what went wrong?
My eclipse version info:
Version: Indigo Service Release 2
Build id: 20120216-1857

If you inspect an expression, eclipse has to execute that expression so you can get the value. Therefore, if you inspect i++, eclipse adds one to i.
Think about it this way: If instead of i++, you inspected myFunction(i), would you expect eclipse to execute the function "myFunction" to get the value? It's the same with i++.

If you are concerned about displaying/showing values while debugging and do you want to be sure not affecting the value, you should select the variable or expression and use the "Watch" option.
This will track the variable/expression value without executing, just updating the new value each time this is run. I think is the most secure way.

As Pablo mentioned, it has to evaluate the code in order to tell you what value it returns. You could instead put a watch on "i+1" and that would give you the value you want without the side effect you don't want.
Basically, you need to be aware of any side effects of anything you launch, whether from the "main" code or from the debugging tools. As Erhannis mentioned, this is very useful at times for modifying values while debugging your code. (For example, you can verify that a tweak/fix is indeed helpful before actually tweaking your code.)
You were expecting "an isolate area" but this would be extremely hard to do, especially in an object-oriented context where many objects are linked to many other objects. Running the whole thing in parallel might sometimes work, but you'd lose the tweaking ability above. And in any context, you'd run into tons of problems with fighting over resources; e.g. both copies trying to read/write a particular file such as a log file. Also, the two execution paths could diverge, leading to incorrect/misleading watch values.
So, preventing such side effects is not really a feasible option here and would rarely be useful anyway. Just expect that the watches can both reflect and affect the code execution.

Log line numbers of executed java code

I am writing part of a PHP web application (which will be used in a high school bug finding contest) where the user must find bugs in a given Java program. As a part of this, when the Java program executes, we want to highlight the lines of the source of the Java program where the code has executed. To do this, all we need are the line numbers of the source that have been executed, that is, the code path (or is it called code coverage?). We will highlight the lines in the source file using the line numbers.
We will be using PHP's shell-exec() to execute the Java program and the tool to get the code path (whatever that will be). What is the easiest way of getting the line numbers of code path?
Thank you very much!
Here is a picture that describes what we would like

PHP interperts the code, which means it runs over the source each time you run the program. This has the benefit of blowing up as the code is read (which makes line number printouts trivial); however, it often is expensive in other ways, as you cannot optimize deeply (or do any pre-runtime error checking).
Java compiles its code into a JVM assembly language called "bytecode." This means that what is running doesn't generally have access to (or even use) the source code. That said, there are techniques. A compiled Java class has the ability to add "extra data" and one of those "extra data elements" is a line number table, which is an index allowing someone running the assembly to "look up" the line number as the compiler recorded it.
This generally works ok, with the considerations that: compilers often don't mark up every instruction, the source code may not be available, optimization might make certain inner chunks of code not function in ways that facilitate pointing to the input code text.
How code coverage tools "fix" this is that they generally insert into the code (at the assembly level) a large number of commands that effectively act as logging statements to a format that allows the tool to determine which path through the code was actually followed. This is then mapped back through the line number table as best as possible and then used to highlight lines within the original source file.
If you want something with finer resolution (something that can process which portion of a line was executed) then you need to dig deeper. Eventually you might even consider writing your own compiler (or compiler extension) which will store your own custom line number table that overcomes the shortcomings of the current solutions.
Tricks like throwing exceptions (as Shiven has mentioned) and parsing out the line number do work; however, they pollute your code with odd exception processing for items that really aren't exceptional, just to "get the line number". Due to the code clutter and the generally poorer runtime performance of exceptions, I tend to avoid such solutions (but they do work).
Anyway, hopefully this will give you a view as to why it doesn't always work exactly the same way as PHP.

You could get a linenumber if you compile the program with the -g option, do a printStackTrace(), capture the trace output and extract the linenumber from there.

Take a look at Cobertura. It computes coverage and stuff like that, and if it doesn't already do it, it should be relatively easy to add the line number collecting to it.
There's a very hackish attempt to do that, but that's so slow that you may not be able to use it in production https://bitbucket.org/jowu/myriapod/wiki/Home

I have never done or seen anything like this but it does seem like an interesting problem. My thought would be to use the java debugger (jdb) to run the code, rather than just the java command.
You can step through the code line by line (via the step command in jdb) and each time a line executes its line number is spit out. This would require a little help from the PHP side (it would have to parse the line number as well as execute the next step command) but the line numbers are there. Here is a sample output from a very basic java program.
Java (TestClass.java)
public class TestClass {
public static void main(String[] args) {
System.out.println("foo");
System.out.println("bar");
}
}
jdb (jdb TestClass after running javac TestClass.java)
Initializing jdb ...
> stop at TestClass:3
Deferring breakpoint TestClass:3.
It will be set after the class is loaded.
> run
run TestClass
Set uncaught java.lang.Throwable
Set deferred uncaught java.lang.Throwable
>
VM Started: Set deferred breakpoint TestClass:3
Breakpoint hit: "thread=main", TestClass.main(), line=3 bci=0
3 System.out.println("foo");
main[1] step
> foo
Step completed: "thread=main", TestClass.main(), line=4 bci=8
4 System.out.println("bar");
main[1] step
> bar
Step completed: "thread=main", TestClass.main(), line=5 bci=16
5 }
main[1] step
>
The application exited

Try referring to this link JVMDI
You can try accessing the values of the program counter and then map it onto the lineNumberTable .
OR
I think JVMDI has a method which can access the line number of the executing code.I'm not sure of the latter,refer the to the link above and hope it helps.

How can I debug my code?

I asked about some non-working code I had at Code works extremely slowly and does not print output.
As you can see in the answer to that question, deks debugged my code and also provided the output of the fib() function. How could I do that by myself? I really know very little about debugging.

To debug, get yourself and IDE like NetBeans or Eclipse. Then instead of clicking run, click on line number then click debug. When the execution gets to this point, it stops, and you can examine the variables that are currently visible. To make sure they have values they should have. For example, if n should be between 1 and 10, and it is 100, then you know something is wrong. Fine where you set n, and add more breakpoints. These are the points were the execution will stop. You can also click step over, to execute the next line, then stop, or step into, which will execute the next line, except it will step into any functions that you used.