Decompiling Java / Edition 1

Decompilers are something of a black box to most programmers. Not unlike compilers. Actually Nolan shows us that the 2 are very similar in their lexical methods. In the specific case of Java, this book may well cause unease in the reader, if you program in Java and are worried about protecting your source code. After all, it probably has proprietary methods that are not covered by any patents you might have. While you can copyright the source, Nolan points out that this may not stop someone from decompiling and reimplementing your 'secret' methods. The book shows that the big problem with Java bytecode is that decompilers for it have a far easier time than decompilers for actual assembly code, whatever the specific hardware for the latter. The basic reason is that the bytecode retains extra information that a decompiler can use, whereas assembly does not have this. Like the fact that the bytecode separates data from instructions. A vital simplification to a decompiler. Nolan shows countermeasures. At the source code level, there are several good obfuscation techniques, described well enough for you to try. And these may be better than buying a commercial decompiler. Also, Nolan suggests fully compiling your Java into specific assembly binaries. One for each combination of microprocessor and operating system that you need to support. More work. But it makes a decompilation far harder. Besides, these days, you may only have to support a few combinations. The hardware may be a Pentium or a Sparc or an IBM cpu. If a Pentium, then you might only support a recent linux or Microsoft OS on top of it. If a Sparc, then you need only support a recent Solaris. While for an IBM cpu, the only choice is AIX or Apple's OS.