This week's book giveaway is in the OCMJEA forum. We're giving away four copies of OCM Java EE 6 Enterprise Architect Exam Guide and have Paul Allen & Joseph Bambara on-line! See this thread for details.
The break statement is essentially a goto (jump) to the label.
This is really ugly code. There's a reason why Java doesn't have a goto statement; it can quickly make your source code a big, unreadable mess (see Wikipedia for details). Please do not use the 'break' statement in your own code like this. The following would have been much better and more readable:
Jesper Young wrote:
Please do not use the 'break' statement in your own code like this.?
Indeed, you should not: but you actually can't, anyway. A break can only break out of a loop; the label marks the loop that is to be exited. The code you've shown won't actually compile; the decompiler has emitted some kind of weird hybrid Java/C because it couldn't find a valid decompilation.
Campbell Ritchie wrote:With that "break" after an "if" I would be surprised if it recompiles.
There's no inherent problem with a break after an if - provided both are inside another structure that allows break. Such as a labeled statement. The problem here is only that the labeled statement is in a position that we can't legally break from, since it doesn't contain the break.
Ernest Friedman-Hill wrote:A break can only break out of a loop; the label marks the loop that is to be exited.
EFH was emphasizing the "out of" part here - but I wanted to add that it's not just loops that you can break out of. An unlabeled break can break from a loop or switch, while a labeled break can break from any labeled statement. Including a labeled block, like this:
That's equivalent in function to Campbell's code above. Not as clear to read, but legal. Whether that's what the code is supposed to do, we don't know, but I think it's plausible.
Matt Kidd wrote:I'm tempted to remove all these label and break statements just so I can compile if possible.
Well, try commenting them out, so you can still see them. Chances are they were trying to do something useful, and until you figure out what that was, you probably shouldn't delete the clues they provide. I don't favor keeping commented-out code around indefinitely, just initially, while you're working out what it's supposed to do.
You may also benefit from using javap, a tool in the JDK for disassembling class files. I'd try something like
to put the output in a file for careful study. It takes some work to make sense of this stuff. I wouldn't make this my primary source for figuring out what the code does (too much work!) but it's good for resolving questions like where, exactly, is the execution supposed to jump to after the break.
Campbell Ritchie wrote:You can't ask whoever developed your application for the code?
Asked my boss and he said no. The enhancement I'm putting in as a stop gap is inherently in the next version.
Has he also given a good reason for saying no? I doubt you spending hours on this is good for productivity, if you can save those hours by asking for the code. If it's commercial code the price may be too high of course, but is that the case?
There was nothing in the code snippet we were given to show the labelled break was part of a loop; it is unusual to see a labelled break in a switch. That is why I said I would be surprised if it re-compiled.