Develop Reference

Why does this for loop compile? [duplicate]

Given the following code sample:
public class WeirdStuff {
public static int doSomething() {
while(true);
}
public static void main(String[] args) {
doSomething();
}
}
This is a valid Java program, although the method doSomething() should return an int but never does. If you run it, it will end in an infinite loop. If you put the argument of the while loop in a separate variable (e.g. boolean bool = true) the compiler will tell you to return an int in this method.
So my question is: is this somewhere in the Java specification and are there situation where this behavior might be useful?

I'll just quote the Java Language Specification, as it's rather clear on this:
This section is devoted to a precise explanation of the word "reachable." The idea is that there must be some possible execution path from the beginning of the constructor, method, instance initializer or static initializer that contains the statement to the statement itself. The analysis takes into account the structure of statements. Except for the special treatment of while, do, and for statements whose condition expression has the constant value true, the values of expressions are not taken into account in the flow analysis.
...
A while statement can complete normally iff at least one of the following is true:
The while statement is reachable and the condition expression is not a constant expression with value true.
There is a reachable break statement that exits the while statement.
...
Every other statement S in a nonempty block that is not a switch block is reachable iff the statement preceding S can complete normally.
And then apply the above definitions to this:
If a method is declared to have a return type, then every return statement (§14.17) in its body must have an Expression. A compile-time error occurs if the body of the method can complete normally (§14.1).
In other words, a method with a return type must return only by using a return statement that provides a value return; it is not allowed to "drop off the end of its body."
Note that it is possible for a method to have a declared return type and yet contain no return statements. Here is one example:
class DizzyDean {
int pitch() { throw new RuntimeException("90 mph?!"); }
}

Java specification defines a concept called Unreachable statements. You are not allowed to have an unreachable statement in your code (it's a compile time error). A while(true); statement makes the following statements unreachable by definition. You are not even allowed to have a return statement after the while(true); statement in Java. Note that while Halting problem is undecidable in generic case, the definition of Unreachable Statement is more strict than just halting. It's deciding very specific cases where a program definitely does not halt. The compiler is theoretically not able to detect all infinite loops and unreachable statements but it has to detect specific cases defined in the spec.

If you are asking if infinite loops can be useful, the answer is yes. There are plenty of situations where you want something running forever, though the loop will usually be terminated at some point.
As to your question: "Can java recognized when a loop will be infinite?" The answer is that it is impossible for a computer to have an algorithm to determine if a program will run forever or not. Read about: Halting Problem
Reading a bit more, your question is also asking why the doSomething() function does not complain that it is not returning an int.
Interestingly the following source does NOT compile.
public class test {
public static int doSomething() {
//while(true);
boolean test=true;
while(test){
}
}
public static void main(String[] args) {
doSomething();
}
}
This indicates to me that, as the wiki page on the halting problem suggests, it is impossible for there to be an algorithm to determine if every problem will terminate, but this does not mean someone hasn't added the simple case:
while(true);
to the java spec. My example above is a little more complicated, so Java can't have it remembered as an infinite loop. Truely, this is a weird edge case, but it's there just to make things compile. Maybe someone will try other combinations.
EDIT: not an issue with unreachable code.
import java.util.*;
public class test {
public static int doSomething() {
//while(true);
while(true){
System.out.println("Hello");
}
}
public static void main(String[] args) {
doSomething();
}
}
The above works, so the while(true); isn't being ignored by the compiler as unreachable, otherwise it would throw a compile time error!

Yes, you can see these 'infinite' loops in some threads, for example server threads that listen on a certain port for incoming messages.

So my question is: is this somewhere in the Java specification
The program is legal Java according to the specification. The JLS (and Java compiler) recognize that the method cannot return, and therefore no return statement is required. Indeed, if you added a return statement after the loop, the Java compiler would give you a compilation error because the return statement would be unreachable code.
and are there situation where this behavior might be useful?
I don't think so, except possibly in obscure unit tests.
I occasionally write methods that will never return (normally), but putting the current thread into an uninterruptible infinite busy-loop rarely makes any sense.

After rereading the question....
Java understands while(true); can never actually complete, it does not trace the following code completely.
boolean moo = true;
while (moo);
Is this useful? Doubtful.

You might be implementing a general interface such that, even though the method may exit with a meaningful return value, your particular implementation is a useful infinite loop (for example, a network server) which never has a situation where it should exit, i.e. trigger whatever action returning a value means.
Also, regarding code like boolean x = true; while (x);, this will compile given a final modifier on x. I don't know offhand but I would imagine this is Java's choice of reasonable straightforward constant expression analysis (which needs to be defined straightforwardly since, due to this rejection of programs dependent on it, it is part of the language definition).

Some notes about unreachable statements:
In java2 specs the description of 'unreachable statement' could be found. Especially interesting the following sentence:
Except for the special treatment of while, do, and for statements whose condition expression has the constant value true, the values of expressions are not taken into account in the flow analysis.
So, it is not obviously possible to exit from while (true); infinite loop. However, there were two more options: change cached values or hack directly into class file or JVM operating memory space.

Debugging recursive methods in Eclipse -- any clever way to avoid getting trapped into ever more nested calls?

A common problem I face when debugging recursive methods is that I can't avoid getting trapped into going deeper and deeper into the stack when I want to debug a given piece of code. The only way to avoid getting trapped is to manually disable the BP and then set up it again after the block of code I'm interested in has been passed.
In the above picture, I just want to do a little stroll over the loop's variables for each iteration, seeing if they're behaving as they should and if all's fine and dandy, but I'm currently only getting the first iteration of each call to combinations!
Any clever ideas to get around this?

Try to use conditional breakpoint if you want to hit the breakpoint only for some condition or for ith recursion depth. If you want to unwind recursion, after some of your testing/validation, while debugging you can change the value of the base condition variable from eclipse debugger.

If you have the ability to modify the recursive method I often do this sort of thing.
int combinations(int, a1, int a2) {
return(combinationsImpl(a1,a2,0));
}
int combinationsImpl(int, a1, int a2, int level) {
if(done) {
// on done
return(value);
}
// you can use level to do conditional break points, prints etc
// you can save the value when it crashes or throws an exception etc
// if you need to see variables in the stack log the level and the variables
// to console or a file and then see on what level values become anomalous etc.
return(combinationsImpl(a1,a2,++level));
}

Correct way to get a value?

As part of my AP curriculum I am learning java and while working on a project I wondered which of the following is best way to return a value?
public double getQuarters(){
return quarters;
}
or
public void getQuarters(){
System.out.println(quarters);
}
***Note: I now that the second option is not "technically" returning a value but its still showing my the value so why bother?

Your answer would be correct. The second method doesn't return any value at all, so while you might be able to see the output, your program can't. The second method could still be useful for testing or even for a command line application, but it should be named something like printQuarters instead.

public double getQuarters(){
return quarters;
}
Use this incorder to encapsulate quarters and hide it from being accessed by other programs. That means, you have to declare it as private quarters. Let see the second option:
public void getQuarters(){
System.out.println(quarters);
}
However, this seems wrong as getQuarters is not returning anything. Hence it would make more sense to refactor it as
public void printQuarters(){
System.out.println(quarters);
}

You answered your own question. For most definitions of the word "best", you should go with the first option.
Your question, however, does touch on the object-oriented programming topic of accessors and mutators. In your example, "getQuarters" is an accessor. It is usually best to use accessors to retrieve your values. This is one way to adhere to the Open/Closed Principle.
Also, the Java community has a coding convention for this and many tools and libraries depend on code following those conventions.

If all you need to do is display the value when this method is called, and you are ok with console output, then your System.out.println method will do the job. HOWEVER, a function that actually returns the variable is much more semantically correct and useful.
For example, while you may only need to print the variable for your current project, what if you came back later and decided that you were instead going to output your variable to a file? If you wrote your getQuarters function with a println statement, you would need to rewrite the whole thing. On the other hand, if you wrote the function as a return, you wouldn't need to change anything. All you'd have to do is add new code for the file output, and consume the function where needed.
A returning function is therefore much more versatile, although more so in larger code projects.

You return values to a specific point in your program, so that the program can use it to function.
You print values at a specific point in your program, so that you as an end user can see what value you got back for some function.
Depending on the function - for instance, yours - the result of quarters is no longer regarded in the program; all it did was print a value to the screen, and the application doesn't have a [clean|easy] way to get that back to use it.
If your program needs the value to function, then it must be a return. If you need to debug, then you can use System.out.println() where necessary.
However, more times than not, you will be using the return statement.

Option 1 is far superior.
It can be easily Unit Tested.
What if the spec changes and sometimes you want to print the result, other times put it into a database? Option 1 splits apart the logic of obtaining the value from what to do with it. Now, for a single method getQuarters no big deal, but eventually you may have getDimes, getEuros, etc...
What if there may be an error condition on quarters, like the value is illegal? In option 1, you could return a "special" value, like -1.0, or throw an Exception. The client then decides what to do.

netbeans debugging best practice

[Edit: Let me rephrase]
Say an object o that occurs in debugging has properties a and b, with values null and Hello. Is it possible to automatically generate the following code for the next debugging session:
if(o.a == null && o.b == "Hello") {
}
When debugging a program that has to cope with complex user inputs, such as a parser for a programming language, I often want to start debugging from a certain point in the process of parsing. I have implemented a simple way of starting when an instruction from a specific line of input code is handled.
However, lines may contain very complex instructions resulting in deep recursions in the code, such that after starting the debugging I have to step farther into the program manually. When this happens in a function func(obj a), I usually write some ugly code like this:
public void func(obj a) {
if(a instanceof someClass && ((someClass)a).hasSomeProperty() && ((someClass)a).getIdentifier().equals("myID")) {
// set a breakpoint here
}
// other code
}
So basically I try to identify the interesting situation by identifying an object that was passed to a function. I know these values because I usually have a breakpoint on an exception that is thrown in the other code. So my question is this: instead of writing all this ugly code to generate a proper breakpoint, is there a way to configure a conditional breakpoint based on some value that a variable has in a former debugging session? Basically say: halt here when the object is exactly like this one here?

You might do the following: write a static utility method ("writer") that serializes and writes the object you want to compare with a future debugging session; and another method ("reader") which receives an Object and compares it with the serialized version, returning true when both are equal.
After that, you can define one or more conditional breakpoints which call up the "writer" method and don't stop.
Additionally, you'd define another conditional breakpoint calling the "reader" method, which halts the thread as usual but only when the condition is met.

Netbeans offers the conditional breakpoint feature: after you set a breakpoint on a line you right click on it, choose Breakpoint-Properties, select the Condition checkbox and insert Java code to express a condition that must be true to break program execution.

add the breakpoint, right click it, go to breakpoint -> properties
at the breakpoint properties window you will see a condition box, and you add your if

Why does code with successive semi-colons compile?

According to my scientific Java experimentation, int x = 0; is equivalent to int x = 0;; which is equivalent to int x = 0;;;;;;;;;;;;;;;
Why does Java allow for this? Does it have any practical application?
Are each of these just empty statements? Do they actually take up any extra processing time during runtime? (I would assume they're just optimized out?)
Do other languages do this? I'm guessing it's something inherited from C, like a lot of things in Java. Is this true?

The extra semicolons are treated as empty statements. Empty statements do nothing, so that's why Java doesn't complain about it.

As Jake King writes, you can produce empty statements to do nothing in a loop:
while (condition);
but to make it obvious, you would write
while (condition)
;
or even better:
while (condition)
/** intentionally empty */
;
or even better, as Michael Kjörling pointed out in the comment,
while (condition)
{
/** intentionally empty */
}
More often, you see it in for-statements for endless loops:
for (;;)
or only one empty statement
for (start;;)
for (;cond;)
for (;;end)
Another thing you can do, is, to write a program, once with one, and once with 2 semicolons:
public class Empty
{
public static void main (String args[])
{
System.out.println ("Just semicolons");;
}
}
Compile it, and run list the size of byte code (identic) and do an md5sum on the bytecode (identic).
So in cases, where the semantics aren't changed, it is clearly optimized away, at least for the 1.6-Oracle compiler I can say so.

Yes, they are empty statements, which don't do anything at all. They are optimized out by the compiler, but in some cases this empty statement actually does something, doing the same thing as a set of empty braces ({}). They are inherited from C syntax, but they have few uses in Java. In C, sometimes doing something like this was useful:
while (condition);
This will loop until condition is false, preventing code from progressing. However, this is discouraged in modern code, and shouldn't ever really be used in Java. However, the empty statement does count as a statement, just a useless one, so constructs like this:
if (condition);
doSomething();
....may cause somewhat baffling results. The if statement will call the empty statement, not the method, so the method will always be called. Just a caveat to keep in mind.

One thing to note is that if you do something like this:
public int foo()
{
return(0);;
}
The compiler will/may complain about an unreachable statement because there's an empty statement after a return. At least with Oracle's 1.6 sdk it does.