goto in Java bytecode

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:

  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.

Answer 1

General background info:

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.

Java & JVM rationale:

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).

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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.