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
Organization: Oracle.
Created: 2012/04/01
Type: Feature
State: Funded
Exposure: Open
Component: core/lang
Scope: SE
JSR: 901 MR
Discussion: compiler dash dev at openjdk dot java dot net
Start: 2012/Q2
Effort: XS
Duration: S
Template: 1.0
Reviewed-by: Duke
Endorsed-by: Edsger Dijkstra
Funded-by: Blue Sun Corporation
Summary
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 goto
is long-overdue and simple to implement since the JVM already has goto
instructions.
Success Metrics
The 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.
Motivation
The 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
functionality, goto.
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
quiche.
The 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.
The 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
Project Lambda.
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.
Description
From its initial version, the JVM has had two instructions for
unconditional transfer of control within a method, goto
(0xa7)
and goto_w
(0xc8).
The goto_w instruction is used for larger jumps. All versions of the
Java language have supported labeled
statements;
however, only the break and 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 ;
The new 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
reused.
Other language changes to support goto include obvious updates to
definite assignment analysis, reachability analysis, and exception
analysis.
Possible future extensions include a computed goto as found in gcc,
which would replace the identifier in the goto statement with an
expression having the type of a label.
Testing
Since goto will be implemented using largely existing facilities,
only light levels of testing are needed.
Impact
Compatibility: Since goto is 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 goto is a VM instruction.
