Powered by HTML coding Best viewed with

FAQ - Frequently Asked Questions

Decompiler issues

Does Jode support Java 5?

It does not support generics/vararg method or the new for loop at the moment. It produces readable code and I think it may even compile again. But it is not compatible as the generics and varargs information is not included.

Jode crashes with ExceptionHandler order failed

Try jode-1.1.2pre1 or the latest CVS version. If it still does not work rewrite jode.flow.TransformExceptionHandlers and send me the fix :)

Since Java 1.4 the format for finally and synchronized blocks changed again. It was always a very difficult task to reconstruct finally blocks correctly and the code is huge and very hard to maintain. With Java 5 it gets even worse.

The decompiler crashes with a VerifyException, what can I do?

The class isn't verifiable, probably because there is not enough information about used classes. See the question about the classpath.

This could also be caused by malicious bytecode, or because there is a bug in Jode's verifier, or because Sun decided to change the definition of correct bytecode, again.

What should be included in the classpath?

Jode needs to know the full class hierarchie to guess the types. This includes not only the classes in the program, but also the libraries used by the java program, even the Java runtime library. You should set the classpath to include all these classes.

If you don't specify the classpath on the command line, Jode uses the same as your Java Virtual Machine.

As last resort, if Jode can't find a class in the classpath it uses reflection to ask the Virtual Machine. This works quite well, but loading classes can have side effects, e.g. when AWT classes are loaded, an AWT thread is created, even though Jode doesn't need it.

Why doesn't Jode decompile my inner class MyClass$Inner.class?

You should decompile the outermost class (MyClass in this case). The produced code contains the inner class.

Obfuscator issues

What should be included in the classpath?

The program, all libraries, the Java runtime library. Don't omit a library even when you don't want to obfuscate it.

What should I preserve

The most common mistake is to preserve a class. In most cases this is not what you want. This only makes sure the class won't be renamed, it doesn't prevent it from being stripped. Instead you should preserve methods and constructors. The constructor is just a method with the special name <init>.

Another common mistake is to omit the type signature, e.g. to preserve Class.main instead of Class.main.([Ljava/lang/String;)V. That doesn't work. If you don't want to care about the format of the type signature use a wildcard as in Class.main.*.

What is a type signature

The type signature is a machine readable representation of a java type that is used all over in java bytecode. The JDK ships a command named javap. With java -s you can lists the fields and methods of a class with their type signatures.

If you are interested in the format of type signatures read the Java Virtual Machine Specification, Chapter 4.3 Descriptors