Decompiling Dalvik to Java, why so many inconsistencies?

I used dex2jar an开发者_JAVA百科d JD-gui on the dex file of an application, although at several parts of the code, it did not make sense and there were error in term of decompilation.

Although when I used backsmali on the dex file, the code was correct but I would prefer to read Java code than Smali to understand how a big app works.

First of all, why so many inconsistencies in the Java code? Is this a problem with dex2jar or JD-gui? Any other alternatives?

Decompilation is usually less-then-perfect even when going from .class files to .java files.

On the one hand that comes from the simple fact that compilation doesn't represent all information from the source file in the .class file. Whitespace and comments are the most obvious examples of information that's not represented in .class files. Local variable names are often left out as well and depending on your compilation flags even argument names might be lost.

On the other hand the market for decompilers seems to be pretty limited and the lack of competition leads to decompilers that don't work as well as the probably could. For example each new release of the Java compiler could produce new code that would need an equivalent update to the decompiler to detect the new patterns and produce the appropriate Java source out of them. Lacking such an update, the decompiler is bound to either fail and print the byte code disassembly instead or produce strange-looking constructs that do the same thing but would never get written by a human.

And when you add another level of compilation (Java Byte Code -> Dalvik Byte Code) then it can only get worse.

Unless you can give a specific example of what kind of inconsistencies you mean it's hard to give a better answer.