Question
So the other day when I was looking at the wikipedia page for Java bytecode I came across this example:
Consider the following Java code:
https://stackoverflow.com/questions/19997009
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian outer:
for (int i = 2; i < 1000; i++) {
for (int j = 2; j < i; j++) {
if (i % j == 0)
continue outer;
}
System.out.println (i);
}
A Java compiler might translate the Java code above into byte code as follows, assuming the above was put in a method:
0: iconst_2
1: istore_1
2: iload_1
3: sipush 1000
6: if_icmpge 44
9: iconst_2
10: istore_2
11: iload_2
12: iload_1
13: if_icmpge 31
16: iload_1
17: iload_2
18: irem
19: ifne 25
22: goto 38
25: iinc 2, 1
28: goto 11
31: getstatic #84; //Field java/lang/System.out:Ljava/io/PrintStream;
34: iload_1
35: invokevirtual #85; //Method java/io/PrintStream.println:(I)V
38: iinc 1, 1
41: goto 2
44: return
And I notice that little word goto appears a couple of times, which upon checking the JVM specification is valid. My question is why? GOTO is a reserved but unusable keyword in Java, so why when we write and compile java code does it seem to get compiled with goto back into it. I am wondering it this is just the way things have always been done at a lower level of programming, or whether it is because the JVM is trusted to use the goto word more effectively. Ultimately I am curious as to why goto is considered such bad practice that it is prohibited in java code, yet seems to be put straight back into your code when compiled.
Solution
Java structured programming features such as loops (for/ while) are implemented at the bytecode level with conditional branch (IF..) and unconditional jump (GOTO) instructions.
break or continue to an outer loop are also considered sufficiently useful & legitimate within structured programming, that the Java language has these features (break/ continue to label).
At the JVM/ bytecode level, these are also implemented with GOTO.
See:
OTHER TIPS
You should distinguish between language keyword goto and byte code or assembly instruction goto.
It is bad practice to use goto jumps in high level code, like in C. Therefore it is not allowed in Java.
The original Edsger W. Dijkstra paper on goto.
In compiled code usage of unconditional jump instruction goto is completely OK. It is put in there by compiler and it does not forget about implications of jumping around the code including initialization of data, deallocating memory etc.
The hardware part of any microprocessor only knows it needs to successively execute every instruction starting from a memory address -- it doesn't even know at which memory address to stop executing instructions.
Assembly language is a very thin converter from "commands" to "binary microinstructions". The list of "commands" does not include control flow statements at all all you have is jump instructions (simple jumps or conditional jumps), that's it (okay, there is an instruction for unconditional endless loops and for conditional loops).
Because of this the control flow statements which are available in higher languages such as C are implemented using these jump instructions because there is no other way to implement them. As it so happens goto in C is compiled into binary instructions as just a simple unconditional jump instruction.
Many different hardware architectures have different standards/formats for "binary microinstructions" and different sets of instructions. The JVM has its own standard and its own set of instructions.
This allows the Java Compiler to always output the same instructions no matter on what hardware architecture the executable will be run; it's the JVM's job to translate an instruction from its own standard into the current machine's standard.
So in essence the JVM bytecode is an "assembly language" for "the java virtual machine". Which means it doesn't have control flow instructions. It has unconditional jump instructions (which happen to be named goto).
break and continue at the lowest level happen to be implemented as a jump (or goto). The point of the matter is that if you use a higher level language you would want to avoid using goto even if it's available (like in C), and would use the more readable control structures.
There are some special cases (in C for ex.) when even programmers who respect all of the "best coding practices" would use a goto for example coroutine implementations.
Some other examples of sacrificing the coding standards for better or more reliable performance is when Kernel developers have architecture specific assembly code (C allows you to write assembly instructions).
Bytecode is some sort of assembly language for the virtual machine. It is very common to have jump instructions in machine language. goto is a unconditional jump instruction.
The Java compiler translates almost all control flow statements inside a method body into goto instructions.
The goto keyword was probably reserved in Java to retain the option to add it to a later version in case it would have turned out that it's existence would have been critical. There is actually nothing wrong with goto from a machine point of view. It has got a bad reputation because it allows to write code that is very hard to read for a human. The Java language allows you to use break and continue with labels as a replacement for goto.
goto is fine at machine level, java compiler are not writing code, it only converts code from java source to bytecode.
For people writing code this is diffrent story, goto instruction are hard to read and analyze and code is the mess after many goto jumps. This is why people should use OO concepts instead of jump instructions.
You're looking at the JVM's equivalent of machine code. Whether goto is permitted in Java is irrelevant to whether it's permitted in the bytecode, just as pointers aren't permitted in JVM bytecode, but the JVM will certainly compile or interpret the bytecode into machine code that does use pointers.
bytecode isn't Java, programs in other languages, like Groovy, can be compiled into bytecode, you can write bytecode directly using some tools like BCEL. As for goto you cannot go without it at low level.
goto keyword and goto instruction are not the same. The only common thing is the name. In case of bytecode it is just an instruction of JUMP (JMP);goto is thought to be a bad practice in programming/coding, because of realizing the 'spagetti' code and making worse the readability of code.Goto statements in programming are one way statements where as function calls are two way switch that is it will return back to the called section of the code.
To use those only bytecodes use goto in them. In case if user is allowed to use goto means we may use it in a inefficient way (say unconditioned goto statement) which will never let the program to terminate.
Jvm is such intelligent that never let the program run infinitely.
