Integrating JAD decompiler into JDeveloper

In JDeveloper, when debugging or otherwise navigating to classes that JDeveloper does not have the source code for, JDeveloper generates a "stub source", showing you only the fields and methods but not the source code. For many years, I have been using a neat "undocumented feature" of JDeveloper, which allows me to integrate the popular decompiler JAD into the IDE, so that I automatically get JAD decompiled code instead of those rather useless stub sources. Recently I wanted to use this feature on someone else’s computer, and, not having my laptop present, I tried Googling for this "undocumented feature", which lived up to its name insofar that I could not find it anywhere. So, before I have a harddisk crash and lose this knowledge for good, I’ll put it in this blog entry 🙂

First step is to dowload the free JAD decompiler, which you can find at this location: http://www.kpdus.com/jad.html#download. There is no installation process to speak of, it contains a single executable (jad.exe in case of Windows) which you can place anywhere on your harddisk. Then, you’ll need to go to open the file "<JDEV_HOME>\jdev\bin\jdev.conf", and add the red lines below to it:

##############################################################################
#
# Oracle JDeveloper 10g Launcher Configuration File
# Copyright 2000-2005 Oracle Corporation.
# All Rights Reserved.
#
##############################################################################
#
# The format of this file is:
#
#    "Directive      Value" (with one or more spaces and/or tab characters
#    between the directive and the value)  This file can be in either UNIX
#    or DOS format for end of line terminators.  Any path seperators must be
#    UNIX style forward slashes '/', even on Windows.
#
# ADDED BY PEBELL
AddVMOption -Djcncmd=c:/progra~1/decomp/jad.exe -& -p -b -ff -nl -pi99999 -space -t2 -noinner
SetBuiltRoot ../../built
AddJavaLibPath ../lib/patches
AddJavaLibFile ../../../classes

Of course, you need to use your own path to where you placed the jad.exe file. The "-p" parameter is mandatory (indicating that JAD needs to write its output (the decompiled source code) to STDOUT, which JDeveloper pipes to the editor window. The rest of the parameters guide the way in which JAD decompiles the code, and are a matter of personal preference. In this example, it indicates that it will use more braces than strictly necessary (for readability), fields will be put above the methods, String constants will break at newlines, imports will not be grouped, spaces will be placed between keywords (like "if") and expressions, indentation size = 2 spaces, and inner classes need not be decompiled. But there’s much more to choose from.

There is, however, one small caveat: when decompiling certain classes, JDeveloper seems to "lock up", in which case you have to kill the jdev.exe process manually and relaunch JDeveloper. Despite this instability (which might be cured with additional JAD parameters, SEE UPDATE BELOW)  I find this a very useful feature (or customization, or hack, whichever you prefer)! Check it out!

UPDATE 

I seem to have found the cause of the instability problem. When using JAD from the command line on one of the "troublesome classes" that lock up JDeveloper, I noticed that some "debug messages" were written to STDERR:

Overlapped try statements detected. Not all exception handlers will be resolved in the method init
Couldn't fully decompile method init
Couldn't resolve all exception handlers in method init

Using the -& JAD option (which I just added to the jdev.conf line above), JAD redirects STDERR to STDOUT. The result when using JAD inside JDeveloper is that these messages are written to the decompiled code (where you get to see them), and that JDeveloper no longer locks up. Happy decompiling!