By Darcy-Oracle on Apr 01, 2012
Work on JDK 8 is well-underway, but we thought this late-breaking JEP for another language change for the platform couldn't wait another day before being published.
Title: Goto for the Java Programming Language
Author: Joseph D. Darcy
JSR: 901 MR
Discussion: compiler dash dev at openjdk dot java dot net
Endorsed-by: Edsger Dijkstra
Funded-by: Blue Sun Corporation
Provide the benefits of the time-testing
goto control structure to
Java programs. The Java language has a history of adding new control
structures over time, the
assert statement in 1.4, the enhanced
for-loop in 1.5,and
try-with-resources in 7. Having support for
is long-overdue and simple to implement since the JVM already has
goto statement will allow inefficient and verbose recursive
algorithms and explicit loops to be replaced with more compact code.
The effort will be a success if at least twenty five percent of the
JDK's explicit loops are replaced with
goto's. Coordination with
IDE vendors is expected to help facilitate this goal.
goto construct offers numerous benefits to the Java platform,
from increased expressiveness, to more compact code, to providing new
programming paradigms to appeal to a broader demographic.
In JDK 8, there is a renewed focus on using the Java platform on
embedded devices with more modest resources than desktop or server
environments. In such contexts, static and dynamic memory footprint
is a concern. One significant component of footprint is the code
attribute of class files and certain classes of important algorithms
can be expressed more compactly using
goto than using other
constructs, saving footprint. For example, to implement state
machines recursively, some parties have asked for the JVM to support
tail calls, that is, to perform a complex transformation with security
implications to turn a method call into a
goto. Such complicated
machinery should not be assumed for an embedded context. A better
solution is just to expose to the programmer the desired
The web has familiarized users with a model of traversing links among
different HTML pages in a free-form fashion with some state being
maintained on the side, such as login credentials, to effect behavior.
This is exactly the programming model of
goto and code. While in the
past this has been derided as leading to "spaghetti code," spaghetti
is a tasty and nutritious meal for programmers, unlike
invokedynamic instruction added by JSR 292 exposes the JVM's
linkage operation to programmers. This is a low-level operation that
can be leveraged by sophisticated programmers. Likewise,
goto is a
also a low-level operation that should not be hidden from programmers
who can use more efficient idioms.
Some may object that
goto was consciously excluded from the original design of Java as
one of the removed feature from C and C++. However, the designers of
the Java programming languages have revisited these removals before.
enum construct was also left out
only to be added in JDK 5 and multiple inheritance was left out,
only to be added back by the virtual extension method methods of
As a living language, the needs of the growing Java community today should be used to judge what features are needed in the platform tomorrow; the language should not be forever bound by the decisions of the past.
From its initial version, the JVM has had two instructions for
unconditional transfer of control within a method,
goto_w instruction is used for larger jumps. All versions of the
Java language have supported labeled
however, only the
continue statements were able to
specify a particular label as a target with the onerous restriction
that the label must be lexically enclosing.
The grammar addition for the
goto statement is:
GotoStatement: goto Identifier ;
goto statement similar to
break except that the target
label can be anywhere inside the method and the identifier is
mandatory. The compiler simply translates the
goto statement into
one of the JVM
goto instructions targeting the right offset in the
method. Therefore, adding the
goto statement to the platform is
only a small effort since existing compiler and JVM functionality is
Other language changes to support
goto include obvious updates to
definite assignment analysis, reachability analysis, and exception
Possible future extensions include a computed goto as found in
which would replace the identifier in the goto statement with an
expression having the type of a label.
goto will be implemented using largely existing facilities,
only light levels of testing are needed.
- Compatibility: Since
gotois already a keyword, there are no source compatibility implications.
- Performance/scalability: Performance will improve with more compact code. JVMs already need to handle irreducible flow graphs since
gotois a VM instruction.