Best class decompiler?
in [Java Programming]
|
From: Joshua Cranmer on 4 Jul 2010 15:00 On 07/04/2010 01:09 PM, Tom Anderson wrote: > It is utterly frustrating that there is no current java decompiler that > is either (a) open source or (b) written in java! Well, there's JODE: open source and written in Java. But it fails miserably when you start throwing in finally and synchronized blocks; it also appears to have problems determining control structure if you have enough nested loops. In any case, interest in decompiling has significantly waned over the past decade or so. A project or two on sourceforge claim to support Java 5 decompilation, but I haven't tested it in depth. -- Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth
From: BGB / cr88192 on 4 Jul 2010 17:16 "Arne Vajh�j" <arne(a)vajhoej.dk> wrote in message news:4c30c519$0$281$14726298(a)news.sunsite.dk... > On 04-07-2010 10:18, Blake McBride wrote: >> The problem is that there are many Java decompilers (such as JAD). A >> brief survey by me indicates that support for high quality decompilers >> seems to be waning. Many appear severly out-of-date. > > 10 years ago people considered it very cool that you could > decompile. > > Today it is old news and only those that for some unusual reason > really need the functionality are inteterested. > I suspect part of the issue may be that most practical uses of decompilation are either questionable (decompiling code for which one doesn't legally have ownership) or nefarious (the previous, but with intent to either steal said code, or attempt to circumvent or exploit). on average, people likely have a valid need for decompilation far less often than they have a valid need for undelete, and it can be noted that as a general rule, people don't usually have undelete either (even if it wouldn't be particularly difficult to implement a filesystem with reasonably good undelete support, few bother, as this is not generally a useful feature...). so, being a tool with relatively few valid uses, means that there is not a whole lot of reason to implement or maintain these sorts of tools. it is rare to even find much need for an unparser (takes ASTs and regenerates an approximation of the original source), whereas this is technically a piece of code with many more possible uses. however, in most cases where an unparser "could" be useful, far more often it is easier just to drag along the original source-code (in some form) and summon it up when needed. or such...
From: Tom Anderson on 4 Jul 2010 19:09 On Sun, 4 Jul 2010, BGB / cr88192 wrote: > "Arne Vajh?j" <arne(a)vajhoej.dk> wrote in message > news:4c30c519$0$281$14726298(a)news.sunsite.dk... >> On 04-07-2010 10:18, Blake McBride wrote: >>> The problem is that there are many Java decompilers (such as JAD). A >>> brief survey by me indicates that support for high quality decompilers >>> seems to be waning. Many appear severly out-of-date. >> >> 10 years ago people considered it very cool that you could >> decompile. >> >> Today it is old news and only those that for some unusual reason really >> need the functionality are inteterested. > > I suspect part of the issue may be that most practical uses of > decompilation are either questionable (decompiling code for which one > doesn't legally have ownership) This is perfectly legal throughout the EU - provided you're doing it for the purpose of writing code to interoperate with the code you're decompiling, and you couldn't get the information you need from documentation. Which, IME at least, is the main reason to decompile something anyway, so when you need to do it, it's legal to do it. > on average, people likely have a valid need for decompilation far less > often than they have a valid need for undelete, and it can be noted that > as a general rule, people don't usually have undelete either (even if it > wouldn't be particularly difficult to implement a filesystem with > reasonably good undelete support, few bother, as this is not generally a > useful feature...). True! tom -- sh(1) was the first MOO
From: Tom Anderson on 4 Jul 2010 19:12 On Sun, 4 Jul 2010, Joshua Cranmer wrote: > On 07/04/2010 01:09 PM, Tom Anderson wrote: >> It is utterly frustrating that there is no current java decompiler that >> is either (a) open source or (b) written in java! > > Well, there's JODE: open source and written in Java. But it fails > miserably when you start throwing in finally and synchronized blocks; it > also appears to have problems determining control structure if you have > enough nested loops. Hmph. Thus proving my barn-raising hypothesis to be false. Oh well. > In any case, interest in decompiling has significantly waned over the > past decade or so. A project or two on sourceforge claim to support Java > 5 decompilation, but I haven't tested it in depth. I wonder if the driver of the fall of decompilation is the rise of open source, and perhaps also open standards. If your landscape consists of, say, the JDK, JBoss, Spring, and Hibernate, then there are easier and more reliable ways to get hold of source code than decompilation. tom -- sh(1) was the first MOO
From: Joshua Cranmer on 4 Jul 2010 19:19
On 07/04/2010 05:16 PM, BGB / cr88192 wrote: > "Arne Vajh�j"<arne(a)vajhoej.dk> wrote in message > news:4c30c519$0$281$14726298(a)news.sunsite.dk... >> 10 years ago people considered it very cool that you could >> decompile. >> >> Today it is old news and only those that for some unusual reason >> really need the functionality are inteterested. >> > > I suspect part of the issue may be that most practical uses of decompilation > are either questionable (decompiling code for which one doesn't legally have > ownership) or nefarious (the previous, but with intent to either steal said > code, or attempt to circumvent or exploit). Researchers have pretty much established that decompilation has substantial valid uses (supposedly, 20% of all source code just simply doesn't exist anymore); I myself had to decompile my own code due to an undiscovered feature in my version control system. > so, being a tool with relatively few valid uses, means that there is not a > whole lot of reason to implement or maintain these sorts of tools. In the U.S., the DMCA does make working on decompilation in a legal gray area; most of the more recent advances in decompilation I've seen have been from non-U.S. researchers. In any case, a skilled programmer can function just as well off of the technically easier disassembly; with a bit of a guide, it is not hard to use javap to go from class code to source code. Seeing as how IDA (probably the most widely used disassembler in existence) has a successful plugin for decompilation, it is clearly not something for which a market is lacking. On the other hand, as has been additionally pointed out, fully automated decompilation of entire programs remains generally impossible under current techniques. Decompilation is typically viewed as another tool for reverse engineering, not the ultimate panacea. -- Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth |