Hi, my name is Brian. I like sunsets, long walks on the beach, puppies, and de-compiling Java code. If you have similar interest, please read on. On the other hand, if you're not a Java programmer, this post might not be for you.
So of all the cool tools out there, JAD is, without a doubt, my absolute favorite...and it's not even close. One of the beautiful things about Java is that the byte-code interpreted by the JVM can be reverse-engineered into source code. JAD, or JavA Decompiler, is a tool for doing just as the name implies: decompiling byte code into source. But so what? Why would this possibly be useful? Well, here's a list of just a few things that I've done by de-compiling code:
-
Found software bugs
-
Saved about 5 weeks of hassle with BEA support by pointing them to the line of source code that is causing a bug
-
Re-compiled bug fixes back into code as a band-aid solution to a problem (Note that this probably voids any/all support agreements that you've ever had with any one)
-
Understood how/why a piece of software works like it does (I.e. "Why is Analytics deleting all a bunch of historic information when I run a specific job...there's no document on it")
-
Found cool/un-documented software features (Again...no support, but playing around with stuff is fun)
-
This one is my favorite: Long ago, for "Bring your kids to work day", I was on the hook for talking to a bunch of 12 year olds about programming. So I de-compiled a Ms. Pacman applet, found the code that does collision detection, modified it to not work, and re-compiled the new code back in. The net result was a Ms. Pacman who could run through ghosts, and a bunch of kids learning how "If" statements work.
-
Also, this guy I know might have one time de-compiled a VI plugin for Eclipse to take out the license key check. Don't worry though, I quickly told him how he was a bad boy, and he's been on the straight and narrow ever since.
OK, sorry for the rambling there, but just wanted to give you a flavor of the stuff you can do by de-compiling code. More generally though, if you're a programmer at heart, it's always a good idea to look at source code, just to understand how things work. Of course there are fringe benefits too:
-
Fellow portal geeks marvel over how "smart" you are because you "de-compiled" the portal and found some problem.
-
You'll get to complain about what idiots the people who wrote the code are
-
Men will want to be you
-
Women will want to be with you
So, let's look at a quick example, shall we? JAD is a text-based utility, so get ready to fire-up your DOS prompts and/or Shell windows. I'm writing this post on a PC, so my examples will be through DOS, but UNIX folks, just make the normal DOS->*NIX changes, and you'll be fine.
Let's assume that I've been trying to get a piece of proprietary software to run for a while now, and every time I start it up, I get a stacktrace like the following:
Now, you could argue that I should know better than to purchase a piece of software named, "Broken", but I'd argue right back that you're getting in the way of my example.
Want to see JAD in action? Join me after the link for all the details!
Anyhow, it turns out that I don't have the source for this application, just a jar file named broken.jar. BUT, I do have JAD, so I figure I that with a little know-how, I can crack open this jar file, de-compile the code, and have a handle on why things are broken in a second. So...first step is to find the class file we want to decompile. From the command line, I know I'm executing the class, "com.foo.bar.Broken", and the only thing in my classpath is "broken.jar", so let's open up the jar file in search of the "Broken" class like this:
Ah-ha, com/foo/bar/Broken.class...from the stacktrace I've been getting, I know the problem is there at line 23 of that source. So let's use JAD to decompile the code. You can do-so from the command-line as such:
Which creates the file, "Broken.jad" in our current directory. My favorite text editor (VIM...For the Win!) doesn't do text highlighting for .jad files automatically, so I usually put the files somewhere safe, re-name them to .java, and open them up to take a look:
So I open up my decompiled source and try to goto line 23, but what's this...line 23 doesn't have any code at all. It's just a brace. Welcome to one of the drawbacks of decompiling code. Because the Java compiler doesn't keep track of things like comments, or what order methods were written in source code, line numbers from stack traces don't match up in your decompiled code. This kind of sucks, but you'll soon get over it. You just need to be fairly decent at reading stack traces, so let's take another look at that trace we've been getting again:
From the stacktrace, I can see that we're getting a NullPointerException in the "doEvenMoreStuffMethod", so let's zero in on that code:
Luckily this is just an example, and it's pretty easy to see that we're trying to run a method on a non-initialized variable. So, let's fix that code real quick by properly initialized the String "s":
And viola...now we have code that should probably work. The next screencap is kind of akin to the home improvement shows where they show you two steps and all of a sudden they have a complete house. But anyhow, we're just re-compiling our fixed code, putting it back in the "broken.jar" file, and running our code to see that it, indeed, works fine:
Thanks for reading...and, Ladies, if the above piqued your interest, feel free to e-mail me at hot4jad@function1.com...we'll do lunch :)
Great post Brian. I have only one thing to add to make this even more simple for all the Java developers out there: jadclipse.
I am not cool enough to use a text editor for all of my java development, so for those of you who want to decompile inline (right click and view source for *any* class), you can make things even easier with this eclipse plug-in: http://jadclipse.sourceforge.net/
Good point Ross, thanks for sharing. In fact, somebody else reminded me that JADClipse is a much easier way to decompile than the method I blogged. For those who are interested and might know him, his name rhymes with "Shomid".
Seriously though people, JADClipse is the way to go if you're doing development in Eclipse. That said, I think it's important to understand /how/ to do things without the IDE magic in the event that:
a) You find yourself somewhere without Eclipse
b) You want to do some quick and dirty work without setting up a project
c) You're old and set in your ways like me :)
Brian, you converted me to JAD long ago. I've never done anything as cool as giving Ms. Pacman immunity, but it's been useful all the same.
Ross, you're so cool that you're not stuck in a text editor for your java development! I find a lower barrier in popping open a command prompt than to figuring out how to get Eclipse to go the right direction for me.
Bi11 |3enac