[...]

May be a bug in jad. Consider reporting it to the jad-developer?
<http://www.kpdus.com/jad.html>

Try running javap -c on the class to see what the bytecode
instructions of the method do. The break will be implemented as a goto
there.

If you want an answer you will have to let people look at the code.

JAD, like any decompiler, makes guesses about what source code will lead to
specific sequences of generated bytecode.  So it depends on being able to
recognise the sequences that the compiler produces.  If the compiler is changed
so that its output follows new patterns, then it's a matter of luck whether JAD
(or any other decompiler) will be able to recognise it.

Since JAD was last updated, which (as far as I know) was at around JDK1.3 time,
the compiler has changed a lot.  One change is that try/finally blocks are
handled very differently; there are undoubtedly other changes.  The final
effect is that JAD is not able to decompile everything into valid Java source.
When that happens it makes an attempt to make the problem obvious in the
"source" and carry on.  That's what you are seeing here.

Personally, I find JAD perfectly adequate for my purposes even though it is a
bit out-of-date.

   -- chris