Holy boop: goto for Java

[markspace]

Just looking for an extended answer to an earlier question (strings in a
case-switch statement), I found this on Joe Darcy's blog:

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

<https://blogs.oracle.com/darcy/entry/upcoming_jep>

Holy booping bat boop Batman!

 

[Daniel Pitts]

Just looking for an extended answer to an earlier question (strings in a
case-switch statement), I found this on Joe Darcy's blog:

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

<https://blogs.oracle.com/darcy/entry/upcoming_jep>

Holy booping bat boop Batman!

Check the date of that article before getting to excited/disappointed ;-)

 

[markspace]

Check the date of that article before getting to excited/disappointed ;-)

Ah. Somebody got me good, I think.

 

[Lew]

Ah. Somebody got me good, I think.

In a highly limited, controlled and presumably blessed-for-object-oriented
way, Java does have a version of "goto", in its 'break' and 'continue'
statements. You can't just jump anywhere, but you can jump to labels, with
restrictions.

I have never seen a use of Java's labeled 'break' or 'continue' outside of
tutorials and examples, though.

The full, unbridled "goto" doesn't exist in Java except for the keyword
'goto', whose head is mounted on a pike at the language's gates as a warning.

 

[Roedy Green]

"Provide the benefits of the time-testing goto control structure to Java
programs.

People take a rule of thumb and turn it into a commandment from a
vicious god.

I remember back in the early 90s in C demonstrating how a common
pattern could be implemented with a goto. The boss insisted on a
goto-less implementation that was many times more verbose. NORMALLY
GoTos make for more tangled code. This time it did not.

Parser generators are simpler if they can generate gotos. Nobody is
supposed to even look at the code.

As a general rule, you don't want them. A team leader would want
members to get permission to use one.
--
Roedy Green Canadian Mind Products
http://mindprod.com
Controlling complexity is the essence of computer programming.
~ Brian W. Kernighan 1942-01-01
..

 

[Robert Klemme]

The full, unbridled "goto" doesn't exist in Java except for the keyword
'goto', whose head is mounted on a pike at the language's gates as a
warning.

I'll print that and put it on our office door. Thanks for that, Lew!

Chuckle...

robert

 

[Arved Sandstrom]

In a highly limited, controlled and presumably
blessed-for-object-oriented way, Java does have a version of "goto", in
its 'break' and 'continue' statements. You can't just jump anywhere, but
you can jump to labels, with restrictions.

I have never seen a use of Java's labeled 'break' or 'continue' outside
of tutorials and examples, though.

The full, unbridled "goto" doesn't exist in Java except for the keyword
'goto', whose head is mounted on a pike at the language's gates as a
warning.

I use labeled break/continue occasionally. I see a lot of advice on
programming forums like StackOverflow that says never use them. Typical
dogmatic advice is that you should extract inner-loop code into methods
and use boolean return codes to make a top-level break/continue decision.

What amazes me is that these individuals support this religious stance
by arguing that it improves readability, when producing little auxiliary
methods usually does anything but.

The combination of conditions that would indicate a labeled
break/continue is clear:

1. A loop;
2. A condition in that loop that could lead to a break or continue for it;
3. That condition is itself a loop. Furthermore, the logic in the loop
is probably coupled to the logic in the rest of the main loop.

To the degree that the logic in that inner loop makes (no) sense as a
standalone method - size, understandability on its own etc - is the
decision process I follow as to whether a labeled break/continue is
advisable.

In any case, Lew, I don't see that this has much to do with "blessed for
OO". We're talking imperative coding here, which is what Java
programmers spend the majority of their time doing.

AHS

 

[Robert Klemme]

What amazes me is that these individuals support this religious stance
by arguing that it improves readability, when producing little auxiliary
methods usually does anything but.

I am not religious about break / continue (although I use it extremely seldom, I am more likely to use "return" inside a loop). But I disagree about your general statement about little auxiliary methods usually not improvingreadability. It all depends on the specific case, of course, but giving ashort part of an algorithm a name (with the option to have a place to put JavaDoc) often helps readability in my experience.

Kind regards

robert

 

[Joshua Cranmer]

I have never seen a use of Java's labeled 'break' or 'continue' outside
of tutorials and examples, though.

If you translate some of the examples in Knuth's retort "The use of GOTO
in structured programming" to Java, you'd find yourself using labeled
break/continue. I've used it a fair amount in nested loops.

 

[Joshua Cranmer]

Check the date of that article before getting to excited/disappointed ;-)

When I first saw that article, I got as far as posting it in an IRC
channel [without context] before I realized it was an joke. Fortunately,
I realized the joke before any discussion started up around it .

 

[Daniel Pitts]

I am not religious about break / continue (although I use it extremely seldom, I am more likely to use "return" inside a loop). But I disagree about your general statement about little auxiliary methods usually not improving readability. It all depends on the specific case, of course, but giving a short part of an algorithm a name (with the option to have a place to put JavaDoc) often helps readability in my experience.

+1

I rarely have methods that are more than 10 lines long anymore, thanks
to "Extract Method" and other refactorings. This sort of goes along with
"self-documenting" code. Now granted, someone could start naming these
auxiliary methods in such a way to be contrary to the goal of
readability, but that's just bad programming. I find a well named
method often removes a hastily written comment. For example:

---
while (isYSquibled()) {...}
---

versus

---
//Loop while x squibles y.
while (x == null || y.canBeSquibledBy(x)) {...}
---

Another thing I've noticed is that programmers are less likely to change
the method to do something-else without renaming the method, but are
more likely to forget or ignore comments explaining what a single line
does.

 

[Mike Schilling]

I have never seen a use of Java's labeled 'break' or 'continue'
outside of tutorials and examples, though.

I've very occasionally found them useful, but they are on the list of things
I wouldn't miss if they were gone. Others:

* Do-while. It seems almost never to be what's needed. Though I do quite
often need

while(true)
{
stuff
if (condition)
{
break;
}
more stuff
}

* Local classes (i.e. named classes defined inside a method)
* The non-short-circuit logical operators & and |

 

[Mike Schilling]

Another thing I've noticed is that programmers are less likely to
change the method to do something-else without renaming the method,
but are more likely to forget or ignore comments explaining what a
single line does.

y = 12; // set Y to 10

 

[Stefan Ram]

y = 12; // set Y to 10

y = 012; // set y to 10

 

[Mike Schilling]

y = 012; // set y to 10

Nice. It's like the proof that Halloween equals Christmas

Dec 25 == Oct 31

 

[Robert Klemme]

I've very occasionally found them useful, but they are on the list of things
I wouldn't miss if they were gone. Others:

* Do-while. It seems almost never to be what's needed. Though I do quite
often need

while(true)
{
stuff
if (condition)
{
break;
}
more stuff
}

Interesting: I cannot remember having needed this. While I do remember
using do {} while. What use cases do you have for the construct above?

* Local classes (i.e. named classes defined inside a method)
+1

* The non-short-circuit logical operators& and |

+1

Kind regards

robert

 

[Lew]

In any case, Lew, I don't see that this has much to do with "blessed for
OO". We're talking imperative coding here, which is what Java
programmers spend the majority of their time doing.

That was rather my point. I should have remembered to include a smiley withthat comment.

Java culture rests on the axiom that Java is an object-oriented language. So if something is built into the language, a circular (and therefore obviously flawed) argument would encourage the sort of foolish remark I made. Examining the foolishness leads to exactly what you said.

So, belatedly,

 

[Gene Wirchenko]

Interesting: I cannot remember having needed this. While I do remember
using do {} while. What use cases do you have for the construct above?

In the sense that there are other ways one can do this, no, you
do not need this. It can be useful if you have multiple tests in that
loop, especially multiple tests that cannot be combined. An example
of this would be a body of:
process first piece
if error
break or continue as needed
process middle piece
if error
break or continue as needed
process last piece

[snip]

Sincerely,

Gene Wirchenko

 

[Lew]

Interesting: I cannot remember having needed this. While I do remember
using do {} while. What use cases do you have for the construct above?

In the sense that there are other ways one can do this, no, you
do not need this. It can be useful if you have multiple tests in that
loop, especially multiple tests that cannot be combined. An example
of this would be a body of:
process first piece
if error
break or continue as needed
process middle piece
if error
break or continue as needed
process last piece

[snip]

public void processResources(String ... resourceNames)
{
for (String name : resourceNames)
{
BufferedReader br;
try
{
br = new BufferedReader(new FileReader(name));
}
catch(FileNotFoundException exc)
{
logger.error("Cannot find "+ name, exc);
continue;
}
assert br != null; // and is valid
try
{
doSomething(br);
}
finally
{
try
{
br.close();
}
catch(IOException exc)
{
logger.error("Cannot close "+ name, exc);
continue;
}
}
reportComplete(name);
}
}

(Not using try-with-resources here, in order to illustrate the idiom.)

 

[Daniel Pitts]

I've very occasionally found them useful, but they are on the list of things
I wouldn't miss if they were gone. Others:

* Do-while. It seems almost never to be what's needed. Though I do quite
often need

while(true)
{
stuff
if (condition)
{
break;
}
more stuff
}

* Local classes (i.e. named classes defined inside a method)
* The non-short-circuit logical operators& and |

I've seen that loop refactored to:

stuff();
while (!condition) {
moreStuff();
stuff();
}


Or:

for (stuff(); !condition; stuff() {
moreStuff();
}


Not saying that is better, just saying I've seen it.