1

I decompiled .jar file with two decompilers, JD-GUI and Luyten, But the result is different.

For example, result from Luyten have namespaces more specific.

Also the source code is different in some lines.

Why two decompilers decompile the same .jar file differently?

rick
  • 1,009
  • 2
  • 10
  • 28
  • Because there are multiple possible Java source codes that can yield the same bytecode. – user207421 Feb 26 '17 at 02:42
  • 1
    The only difference between *"java source codes"* that would yield the exact same bytecode would be based on syntax. The bytecode rick is looking at already is compiled. The decompilers handle translation differently. For instance, if you were to copy paste out the output of JD-GUI, CFR, Procyon, and Fernflower into a java file and compile it they would not all generate the same exact bytecode. Sure it would function the same *(excluding edge cases)* but that's not the point. The point is that the process of translation of bytecode back into java is different between any two decompilers. – Display Name Feb 26 '17 at 20:50

1 Answers1

1

The decompilers you list use different backends for handling the parsing of java bytecode.

  • Luyten uses Procyon.
  • JD-GUI uses JD-Core (No source available).

You can think of decompilers like different scholars translating ancient text into modern English. The source material being transcribed by the scholars "Luyten" and "JD-GUI" is the same, but each scholar transcribes the text differently. Both create modern english that usually is fairly legible but each have their own minor differences.

For example: If the ancient source material stated that "a man reached down and picked up an apple" the scholars may say:

The man picked up an apple.

The man grabbed an apple.

Both get the meaning across but they are slightly different. Sometimes one may understand a odd quirk of the source material more than the other, and thus will produce more accurate results than the other.

For example, JD-GUI can't decompile a method if the last instruction of a method is the last one in a try-catch block but Procyon will be able to translate it into java it just fine.

Community
  • 1
  • 1
Display Name
  • 942
  • 1
  • 10
  • 20