Nowadays everybody seems to pull their libraries from Maven Central, which encourages to upload both the binaries and the source code of a library. Most developers follow the guidelines, so nowadays it has become painless to read the source code of the open source libraries you use. Debugging such a library usually is pretty simple. You don't have to look for the source code, it's just there.
Still, every once in a while you're looking for a bug occurring in a library without source code. In such a situation a Java decompiler comes in handy. It analyzes the Java byte code and tries to reconstruct the original source code. Some things get lost, of course, such as comments. However, depending on how the library has been compiled, even the original line numbers and the variable names can be reconstructed. That's a huge difference to languages like C that compile to native machine code.
JAD
The decompiler I used for years fell into negligence with the advent of Java 1.4. However, Thomas Varanenackas still mirrors various versions. Work on Java 9 already has begun, so this feels a bit like software archeology. Don't get me wrong: I'm very grateful people store and value historic stuff. It's astonishing how fast knowledge falls into oblivion in the internet.
(At the same time it's true the internet never forgets - especially embarrassing posts - but that's another story).
Java Decompiler
Today a co-worked showed my a Java decompiler that works with current versions. It's simply called Java Decompiler. According to the web site it supports most JDKs up to 1.7 and a few other compilers: jrockit90_150_06, jikes-1.22, harmony-jdk-r533500, Eclipse Java Compiler v_677_R32x, 3.2.1 release. It's available as a stand-alone version with GUI, as an Eclipse plugin and as an IntelliJ plugin. Maybe even more interesting is its live demo on Java Decompiler's web site. Just drag and drop your jar or class file to the web file, and it's decompiled. It tried it with AngularFaces, and it worked flawlessly.
A also put the stand-alone GUI version to a very short test. I'm very careful to recommend tools I haven't tested thoroughly, but judging from the first impression it's a clear recommendation.
CFR
CFR is a decompiler swallowing every modern Java version including Java 8 lambdas. It's a command line tool that's written in Java 6, so it's also suited for more conservative companies. The first thing that caught my eye was the long, long list of command line parameters. 48 parameters to influence the code generation - clearly a sign (although no guaranty) of maturity. It ran flawlessly on my short test. Among other things I fed CFR with the cfr.jar itself. Only the to-do-list indicates the program isn't perfect (but remember, I only did a short test, so take my words with a grain of salt).
Maybe even more interesting than the jar file is the website http://benf.org/other/cfr/. The author exhibits a number of interesting implementation details of Java.
What about alternatives?
For one, there's the built-in disassember of the JVM. For those among you able to read byte code, or who are interesting in learning byte code, that's an interesting tool. Second, there seems to be a number of new decompilers: Procyon, Krakatau and Candle, and several more that seem to be less commendable. I didn't test any of them, so suffice it to mention the names. Use at own risk.
Your opinion?
I'm curious about your comments: Do you have experience with a decompiler? Do you know a decompiler I didn't mention? Do you know a decompiler for other JVM languages such as Scala, Groovy, Kotlin or Ceylon?
Wikipedia on decompilers (covering any language, not only Java)