| Java Articles » JVM » Bytecode |
The small print: "Bytecode Basics" Article Copyright (c) 1996 Bill Venners. All rights reserved. "Conversion Diversion" Applet Copyright (c) 1996 Artima Software Company. All rights reserved.
The problem of preventing Java byte-code decompilation is almost as old the language itself. Despite a range of obfuscation tools available on the market, novice Java programmers continue to think of new and clever ways to protect their intellectual property. In this Java Q&A; installment, I dispel some myths around an idea frequently rehashed in discussion forums.
The next few sections will give an introduction to the Core package of the ASM framework. To get a better understanding of the organization of this package, you have to have some basic understanding of the bytecode structures that are defined in the JVM specification. Here is a high-level diagram of the class file format ([*] marks repeatable structures).
The ASM bytecode manipulation framework has been designed and implemented to be small and as fast as possible. ASM's runtime .jar is only 25KB, compared to 350KB for BCEL. The load time overhead caused by class transformation with ASM is about 60 percent with ASM, compared to 700 percent or more with BCEL. These factors have been recognized by the Java community and several well known projects have switched to ASM, such as CGLIB and AspectWerkz. The list of projects that are using form the beginning ASM also includes Speedo, Groovy, dynaop, BeanShell, and a number of others.
The previous article in this series showed how the ASM toolkit can be used to generate new code, and modify existing classes by adding or changing code. This is suitable for many cases, but there are times when it is necessary to stick some meta-information into the class bytecode and then access it later on. A typical example of such metadata is the annotation facility introduced in J2SE 5.0.
While it's always possible to begin our discussion of Java bytecode by simply asserting some facts ("Java bytecode is stored in a tree format"), given that most of the audience is already familiar with Java, it's easier to start by going the opposite direction: we'll take working Java-compiled code, and disassemble it. That way, we've got a working framework (that is, your understanding of the Java language) from which to hang various points about the Java bytecode format. We begin with every Java programmer's first program, the ubiquitous traditional "Hello World" app.
In the last three articles of this series, I've shown you how to use the Javassist framework for classworking. This time I'm going to cover a very different approach to bytecode manipulation, using the Apache Byte Code Engineering Library (BCEL). BCEL operates at the level of actual JVM instructions, unlike the source code interface supported by Javassist. The low-level approach makes BCEL very good for when you really want to control every step of the program execution, but it also makes working with BCEL a lot more complex than using Javassist for cases where both will work.
One possibility for dual source/bytecode support in JiBX 2.0 might be to build on Javassist's source code handling by always generating source code and then using Javassist to convert it to bytecode when class files are being enhanced directly. But Javassist's source code support is limited and includes some idiosyncrasies that differ from standard Java source code (including the way method variables are referenced). Javassist is also slower than some of the other bytecode libraries (ASM, in particular, as discussed in "Classworking toolkit: ASM Classworking"). I'm expecting bytecode enhancement to remain the main focus of JiBX 2.0, and in some circumstances (such as using JiBX in combination with an IDE's automatic compilation), the bytecode enhancements may need to be done repeatedly, so I see speed as an important concern. Finally, the Javassist GPL license is not compatible with JiBX's BSD license. For all these reasons, I'm going to take a different approach.