JDEclipse: A must-have Java Decompiler

I have recently discovered this new, must-have Eclipse plugin, which is very useful for those third-party libraries whose source-code you can’t easily find or link into your Eclipse: JDEclipse.

It doesn’t only decompile byte code into Java code, it does so extremely well, keeping line numbers at the correct place, such that you can actually debug through the decompiled source code and set breakpoints that actually work.

Read more about JDEclipse here:

Note that of course you shouldn’t decompile any code whose license doesn’t allow you to do so…

9 thoughts on “JDEclipse: A must-have Java Decompiler

  1. this is very interesting! recently i’m looking for some tool to decompile in java class file bytecode generated compiling scala, in order to make a clear comparison. Any idea on that? :-)

    1. No, I haven’t played around with Scala enough yet, to get this far. I’d imagine it is a lot more difficult to decompile byte code into Scala than Java, as Scala is much more expressive than Java – meaning that a line of Scala will result in 3-4x as much byte code compared to a line of Java

      1. actually my target is to start from scala source and decompile the corresponding bytecode into a java source. I have done some experiment but for some reason the process produce some problems. Does the plugin you suggested decompile also the JDK 1.5+ bytecodes? (it is the minimal requirements for scala, i think)

        PS: you should really go on scala, for JOOQ too it would be a very improvement, as the fluent interface really fits into the DSL/matching approach :-)

    2. I don’t think that’s possible. Scala composes byte code quite differently from Java. With Scala-generated byte code, there may simply not be any matching Java-the-language expression to compose the same.

      About jOOQ-Scala, there is already an extension leveraging implicit defs for a better Scala integration: https://www.jooq.org/doc/2.6/manual/getting-started/jooq-and-scala/

      In the near future, I’ll be evaluating the impact of Scala Macros for the jOOQ API.

      1. uhm, sad to hear that it’s not possibile, but you are probably right… the idea seems good for courses in order to let programmers identify the benefits of the transition from java to scala :-)

        good to hear about the scala extension, i’ll check as soon as possible thanks ;-)

        1. Well, the benefit/cost discussion is strongly biased of course. In terms of syntax, it can be seen easily where Scala is stronger than Java (today), without even resorting to byte code. Just show a filtering / mapping / reducing algorithm, comparing a Scala-one-liner, with a boring 15-line Java block. However, the lack of lambda expressions and extension methods will be adressed in Java 8. After that, I’m not so sure if there are any “obvious” benefits in using Scala rather than Java… Type-inference looks like a low-hanging fruit at first (val/var rather than explicit declarations). But it also imposes a huge burden on the compiler, apart from introducing a lot of potential for ambiguity… The same applies for implicit defs, not to mention the lack of proper tooling for those that want to use an IDE. We’ll see where this all goes :-)

Leave a Reply