72

What is the difference between a standard while(true) loop and for(;;)?

Is there any, or will both be mapped to the same bytecode after compiling?

tshepang
  • 12,111
  • 21
  • 91
  • 136
sjas
  • 18,644
  • 14
  • 87
  • 92
  • 3
    Have you tried compiling it and looking at the byte code? – David M Jan 16 '12 at 13:45
  • 3
    Nothing: http://stackoverflow.com/search?q=for+while+true – Lasse Espeholt Jan 16 '12 at 13:45
  • possible duplicate of [for(;true;) different from while(true)?](http://stackoverflow.com/questions/440694/fortrue-different-from-whiletrue) – Daniel Fischer Jan 16 '12 at 17:13
  • See also: [Is “for(;;)” faster than “while (TRUE)”? If not, why do people use it?](https://stackoverflow.com/questions/2611246/is-for-faster-than-while-true-if-not-why-do-people-use-it) It's for C, but the answers mostly still apply. – Boann Sep 30 '15 at 18:03

9 Answers9

123

Semantically, they're completely equivalent. It's a matter of taste, but I think while(true) looks cleaner, and is easier to read and understand at first glance. In Java neither of them causes compiler warnings.

At the bytecode level, it might depend on the compiler and the level of optimizations, but in principle the code emitted should be the same.

EDIT:

On my compiler, using the Bytecode Outline plugin,the bytecode for for(;;){} looks like this:

   L0
    LINENUMBER 6 L0
   FRAME SAME
    GOTO L0

And the bytecode for while(true){} looks like this:

   L0
    LINENUMBER 6 L0
   FRAME SAME
    GOTO L0

So yes, at least for me, they're identical.

Óscar López
  • 232,561
  • 37
  • 312
  • 386
  • 7
    Accepted this answer for having provided the code and how it was looked up. Thank you. :) – sjas Jan 16 '12 at 16:56
  • 2
    for(;;) is the cleaner version, imo (also shorter :P) – bestsss Jan 22 '12 at 20:46
  • 1
    Note that in VS while(true) causes compilation warnings on the highest settings for C and C++ (C#?). Perhaps not an issue for Java, but if you write in other languages sometimes, `for(;;)` is a better habit to develop. – T.E.D. Sep 18 '13 at 15:52
  • 1
    In java source they tend to use for(;;), so I just follow what the pro's do :D – Ogen Apr 15 '15 at 07:05
  • `private static final boolean NO_BREAK = true;`. Unless you (also) use `return` of course :) – Maarten Bodewes Dec 12 '19 at 06:53
29

It's up to you which one to use. Cause they are equals to compiler.

create file:

// first test
public class Test {
    public static void main(String[] args) {
        while (true) {
            System.out.println("Hi");
        }
    }
}

compile:

javac -g:none Test.java
rename Test.class Test1.class

create file:

// second test
public class Test {
    public static void main(String[] args) {
        for (;;) {
            System.out.println("Hi");
        }
    }
}

compile:

javac -g:none Test.java
mv Test.class Test2.class

compare:

diff -s Test1.class Test2.class
Files Test1.class and Test2.class are identical
sjas
  • 18,644
  • 14
  • 87
  • 92
4ndrew
  • 15,354
  • 2
  • 27
  • 29
  • I did a little test. Decompiling the classes in jd-gui shows `for(;;)` and NOT `whilte (true)` for both classes! – vedi0boy Jan 08 '18 at 22:05
  • @vedi0boy at JVM level (and bytecode) — there is no difference, jd-gui selects the most easiest way to show this loop. – 4ndrew Jan 11 '18 at 11:38
  • @4ndrew of course I am aware of that, I was just curious how the decompiler sees it. It seems like `while(true)` is not "liked" as much. – vedi0boy Jan 12 '18 at 16:13
8

It compiles down to the same byte code, and it is a matter of taste which construct you prefer.

I read a lot of source code from the Oracle distributed JDK, and I cannot easily remember that I've seen a while(true) statement in their code, but I have seen a whole lot of for(;;) statements in their code. Me personally, I favor for(;;) and my reasoning goes a bit like this:

The while-loop "should" require a boolean expression, not a boolean constant. while(true) is a bit like if(true), both of which I think has been made legal only for the added comfort of the masses. An empty while() does not compile. Adding the true in there feels a bit like hacking.

for(;;) on the other hand is a "real loop", albeit an empty one. Also, it saves you a couple of keystrokes! =) (not that it matter)

Therefore, and I know it sounds crazy, but although while(true) reads better in English, I think for(;;) better express your intent and is more akin to the Java programming language. Eternal loops should be avoided anyways. When I read for(;;), I feel secure knowing the developer will brake the execution path somewhere. When I read while(true), I just cannot be that sure anymore. But hey, maybe that's just me! We're all free to pick our own flavor.

Martin Andersson
  • 18,072
  • 9
  • 87
  • 115
6

On Oracle Java 7 you get the same byte code. You cannot tell from the byte code which was using in the original. Which is best is a matter of taste. I use while(true)

Peter Lawrey
  • 525,659
  • 79
  • 751
  • 1,130
3

I have looked at the generated byte code and found that since the condition is always true (at compile time), the compiler will compile away the test and just branch always back to the top of the loop. I assume that a continue statement will also do a branch always back to the top of the loop. So, not only does it not make any difference, there isn't even any code generated to test anything.

3

Depending upon the compiler, it should map to the same byte code.

DMCS
  • 31,720
  • 14
  • 71
  • 104
3

JVM will find the best way to make bytecode and in both cases should do the same.So I think there's no difference. while(true) is just prettier.

shift66
  • 11,760
  • 13
  • 50
  • 83
2

Functionally there is no difference. Any efficiency gained or lost by a difference in bytecode will likely be insignificant compared to any instruction you would run in the body of the loop.

Dev
  • 11,919
  • 3
  • 40
  • 53
1

Only the difference is required time for the parser, the two distinct expressions include different number of tokens to be parsed however the computation time difference is very low and the compiled bytecode is the same for two cases.

jbytecode
  • 681
  • 12
  • 29