How do Java decompilers work

Java blog for programmers

The Java compiler generates a class file from the source code file and the decompiler reverses the working method. Decompilers are available for the various programming languages, and Java is one of the languages ​​for which back translation is easier than for optimized machine programs that, for example, generate a C ++ compiler. The reason is that the bytecode contains a lot of valuable information that does not appear in conventional machine code. This includes type information or information as to whether a method call is virtual or not. They are important for the Java runtime environment and are of great help when it comes to resuscitating lost source code with a decompiler or to access missing information from packages from third-party manufacturers.

A decompiler reads the class file as a byte field and begins the analysis. Since the bytecode is well documented, extracting variable or method names is easy. The instructions are difficult. From the Java bytecode for a method, a decompiler builds a control flow graph and tries to recognize instructions and expressions that must have arisen when translating certain language constructs. This is a non-trivial task and is still the subject of some diploma theses. And since variable names may have been made invalid by an obfuscator, a good decompiler must correct these illegal identifier names and undo further tricks of the obfuscator. This renaming does not change the algorithm, and a decompiler is easy with this type of obfuscation.

Is that legal? If we let go of a decompiler on our own program code because the source code has disappeared, for example, the application is not a legal problem. Reverse engineering of entire copyrighted applications need not necessarily be a problem. Rather, the offense begins when this source code is changed and sold as a personal contribution.

Since there are now other compilers on the market that generate Java bytecode - for example from EIFFEL programs or from various LISP dialects - cross-compiling is conceivable via the detour compiler / class file / decompiler. Here, however, there are some restrictions with regard to the decompilers on the market. Because third-party compilers that create Java bytecode have other techniques that the decompiler cannot always translate appropriately.

Java Decompiler project (JD) and alternatives

The market for powerful decompilers is very clear. The best tool (but also not entirely bug-free) is currently JD ( The freely available - but not open source - program is available as a library JD-Core, as a stand-alone graphic application JD-GUI and Eclipse plug-in JD-Eclipse. JD itself is written in C ++ and therefore does not require a JVM. JD processes the bytecode of various compilers, whereby JDK 1.1 to JDK 6 is of course included in the list, as is the Eclipse compiler. (The distinction is not entirely uninteresting, as the compilers differ in certain details in the bytecode mapping.) JD-GUI is available for the Windows, Linux and Mac platforms under /? q = jdgui # downloads available and offers, in addition to the decompiling of individual Java classes and entire Java archives, a pleasant source code display with colored background and drag & drop.

The decompiler Jad was the reference for a long time. But Pavel Kouznetsov only developed the command line program in C ++ from 1997 to 2001 and then took his website offline in 2009. However, a private person has mirrored the website and the project continues (for an indefinite period) at If you want to decompile projects up to Java 1.4, you are well served with the tool. For Java 5 projects, JadRetro ( helps a little by adapting Java 5 bytecode to Java 1.4 and making small changes in the bytecode. FrontEnd Plus is a graphical user interface for Jad, but it has also disappeared from the Internet since Jad no longer officially exists. A plug-in for Eclipse is also available at, the end of which has also been announced.

similar posts

Posted in island