::The ethics of decompilation :: [/tech/java] (08:49)

On the Apple java-dev list, an industrious young programmer posted about how he was curious how a certain piece of commercial code works and decided to decompile the code. Of course there was the larger issues of what he developer planned to do with the code and why he didn't just ask the developer (apparently this was a small "shareware" product of sorts). However, a large portion of the debate came from people ardently condemning decompilers as evil.

Is there anything (ethically) wrong with decompiling commercial software? No. A decompiler should be a standard tool of ANY senior level Java developer. Decompilation has been a necessity on the Java projects I've worked on. I've written about the extreme arrogance of obfuscation and a how I feel you are doing your users an extreme disservice my obfuscating code. I can understand why people might be insecure about their code (usually lack of quality and lack of any true intellectual property), and so I suppose I can understand why some people shiver at the thought that their code might be decompiled. But, decompilers have saved me so many times that there is no doubt in my mind about whether or not decompilation is a good thing.

The primary use of a decompiler is understanding why the code that you are using is broken. I know every vendor wants to believe they sell solid, well-architected products and that if something should happen to be wrong that they have knowledgable support staff who can quickly help you out. But it is simply not true. Most commercial code (especially Java products developed during the boom) is hacked together barely functional garbage. Even if you've managed to steer clear of the the bottom of the barrel companies, chances are you are using code the it is exceptionally buggy.

I worked with a popular object persistence framework at a prior company. They did a good job for the most part and they tried to put out good documentation and they provided reasonable, but slow, service. However, the object persistence framework was so fundamental to our product that we simply could not risk depending on their support to diagnose our problems. (we even had a multi-million dollar contract with the company in question) The only sensible thing to do for the more urgent problems was to decompile the code and locate the problem in parallel to their support team. Whether the problem was on our end or was bug deep down in their product, we usually found the problem more quickly and could either fix it or guide their support team to the real problem so they could get a patch out.

We also had a problem with a popular app server a few years ago. The servlet engine had a problem with doing jsp includes that containted a relative path name. We submitted the bug several time, but they never managed to fix the problem. It wasn't critical to us since we could work around the problem. Eventually, I was bored enough to decompile that code. It took me all of 10 minutes to find the bug in their code. I passed the information along to our support contact. I hope they finally fixed the problem in the product. I had moved on to other projects before I had a chance to find out.

I can't count the number of times I have needed look inside a third party library that was silently eating exceptions or look into the code to understand how a poorly documented API call works. It would be nice if everything worked. It would be nice if everything was documented. It would be nice if companies would truly care about their customers and provide source code. Until then, I don't go anywhere without a decompiler close to my side.