In Memory of Stiver | The IntelliJ IDEA Blog

On October 20, the original author of the Fernflower Java decompiler, Stiver, passed away after a long fight against glioblastoma.

Stiver was a German programmer of Russian origin, primarily developing software for medical equipment. Twenty years ago, he developed a deep professional interest in Java virtual machine internals. You may remember his research blog posts, like this one (in Russian) from 2006 about how to tweak the Java class hierarchy using Unsafe when Java 1.5 was just released. Around 2008, Stiver became fascinated by Java decompilation.

The Java decompilation landscape was very poor at that time. The first generation of decompilers like JAD or JODE came to an end. While Java as a language evolved, the existing decompilers were mainly unmaintained, which limited their usefulness. New language constructs like assertion statements, annotations, and generic types were not supported. Moreover, the deprecation of JSR/RET instructions in Java bytecode caused a significant difference in how try-finally blocks are compiled. The decompilers failed to handle the new bytecode.

Another big problem with existing decompilers was their approach to decompilation. They simply looked for specific bytecode patterns and translated them to the corresponding Java statements and expressions. While simple, this approach is fragile – any minor semantically equivalent change in generated bytecode made proper decompilation impossible. This severely limited the decompiler application.

Stiver decided to write his own decompiler as a side project. To overcome the weaknesses of existing alternatives, he took a different approach. After reading the bytecode, he constructed a control-flow graph in static single-assignment form, which is much better to express the program semantics abstracting the particular shape of bytecode. At the beginning of this project, Stiver knew little about static analysis and compiler design and had to learn a lot, but the effort was worth it. The resulting decompiler produced much better results than anything available at that time. It could even decompile the bytecode produced by some obfuscators without any explicit support.

Stiver did the main development himself between 2008 and 2010. The first public version became available in May 2009 as a web service. A user could upload an individual CLASS file or a whole JAR file and get the decompiled result. The decompiler quickly gained popularity – during the first four months, users decompiled more than half a million Java classes. There was no public standalone version, but Stiver sent it privately to a few Beta testers. After the release, Stiver made numerous improvements and fixed many bugs thanks to early adopters.

After 2010, the active development of the decompiler stopped, as Stiver became busier with his primary job. A few third-party software vendors asked Stiver to provide the decompiler for their projects. Notably, it was used with permission in Mod Coder Pack, which is a toolkit for creating mods for the game Minecraft. Still, it became difficult for a regular Java user to find a working version of Fernflower.

In 2013, JetBrains approached Stiver with a suggestion to include Fernflower in IntelliJ IDEA. Part of the deal was making Fernflower open source. Everything went well, and the contract was signed. On July 11, 2014, the early access version of IntelliJ IDEA 14 was released, including the decompiler for the first time. You can still see the initial import of the Fernflower source code in the IntelliJ IDEA Git history, on March 4, 2014.

While Stiver was never a JetBrains employee, he helped improve the decompiler for almost a year after the initial import. As Java 8 had just been released, it was necessary to support new language constructs like lambdas. Another big challenge was integrating the decompiler with the IntelliJ IDEA debugger. Line numbers in decompiled code differ from line numbers in the original source, and Stiver helped provide a transparent mapping between them so you can seamlessly debug decompiled code.

As Fernflower became open source, many other tools in the Java world used it – you can find a number of forks on GitHub. The Java team at JetBrains is constantly improving Fernflower, but it’s still mainly Stiver’s code. If Fernflower hadn’t existed, we likely would have had to invest substantial resources into developing our own decompiler. This could have resulted in IntelliJ IDEA lacking a decompiler or having one that was significantly less effective. Stiver’s work was a real game-changer for Java developers over the past 10 years. With no better alternative to decompile Java bytecode, his contributions have saved developers countless hours while debugging Java code without sources. 

Thank you, Stiver! We are deeply saddened by the loss of such a brilliant pioneer whose work and dedication had such a lasting and profound impact. 

Subscribe to IntelliJ IDEA Blog updates