Decompiler Round-Up: Regenerating Your Code
The following commentary is from the flurry of e-mails that were posted here on the .NETDJ Web site regarding the article entitled "Decompiler Roundup" (.NETDJ, Vol. 2, issue 8).
This article is bizarre. The author makes a lot of effort to downplay .NET Reflector, which is the tool everybody on the street is using (it was rated one of the top 10 developer tools). Next, he is comparing more expensive tools but only along the criteria that make Decompiler.NET look good. The code output example isn't correct or maybe just outdated (again it makes Decompiler.net look good). The comment "how each could handle pointers, because they are my favorite aspect of programming" makes this way too obvious.
-Mario
I was pleased to see the author's unbiased review confirming his positive experiences using our product. I've done my best to send bug reports regarding code generation issues to each of my competitors regarding their products, including the bugs exposed by the examples the author has chosen in this article. I reported most of these bugs to the authors of the products mentioned here including Reflector 4.0 back as early as 04/2004. The newsgroup discussions in which I had participated regarding code generation accuracy occurred prior to this article being written and I personally made all of the vendors mentioned in the article aware of code generation problems in their products. Each vendor had ample time to address these code generation issues prior to this article being written, and their response time is a good measure of the level of support that they provide for their products.
The author just asks each developer to take the time to evaluate each product on his/her own. His conclusions are still accurate, even with newer versions of each of the products available that he reviewed. Decompiler.NET still generates higher-level and more accurate code that the other tools reviewed by the author in this article, and I'm aware of several additional code generation problems that still exist in current versions of the products mentioned here that cause them to continue to generate code that won't compile or run correctly. The author's conclusions are still 100% accurate and each developer can confirm this by downloading the trial versions of each of the products as the author recommends in his article. Please download a free trial version of our product yourself and confirm that it is still the best alternative for your needs at www.junglecreatures.com.
-Jonathan Pierce
The author is not unbiased. Just read this:
"I chose to leave these two tools out of this article. Why? Well, for the same reason I don't do my own electrical work."
"They do not offer the needed level of support."
[Three times in a row. Apparently they do, his example runs fine in the current version.]
"Decompiler.NET with obfuscator is available for $500 per CPU, giving it leverage over its toughest competitor" [Please click here to purchase without thinking]
-Anonymous
Reflector is an excellent tool that I use for casual browsing and code generation comparison. However, there are still many instances where Decompiler.NET generates higher- level and more accurate code, which is important to most professional developers. The current version of Reflector was released after this article was published and addresses these specific bugs over 4 months after they were reported to the author. There are many other code generation bugs in the current versions of the tools mentioned here that were not covered by the article.
The author also made the point that Decompiler.NET was the only tool that generated code that had correct compile and runtime behavior for all of the test cases that he attempted including his Hypersonic example. This is not the case for any of the tools that he evaluated, including the current release of Reflector 4.0.18. I've sent several bug reports to Reflector's author that still exist in his current release regarding many code generation issues not covered by this article.
-Jonathan Pierce
Did the author of this article report those bugs to the tool authors or did you tell him what to write about?
-Anonymous
The author of this article contacted each of the vendors on his own and requested permission to include their product in his evaluation. The article was written entirely by the author including his code examples chosen by him based on his own experiences with each of the products he tested for his own needs. He was trying to identify unusual test cases to measure the robustness of all of the products included in his evaluation. From his conclusions, it appears that he was unable to identify any cases where Decompiler.NET didn't generate correct code to meet his needs. There are many other cases where the other products fail, so I'm not surprised that the author was able to identify some common cases that affected him personally.
I have always encouraged developers to try each of the products themselves and form their own opinions about their accuracy. This article seems to point them in the correct direction so that they can confirm its conclusions themselves before purchasing any of the products mentioned.
-Jonathan Pierce
Okay, let's leave it that way. The article has too many coincidences and you are too well informed on what the author did and didn't do to make it believable. All the tools mentioned are very nice and no harm done if everybody is doing his own evaluation...
-Anonymous
The author isn't unbiased. The scoring card and the careful phrasing to ditch Spices and Salamander shows this. Also, he is leaving half the tools (Anakrino, Reflector, LSW) out, only giving a "doing his own electrical work" argument as a rationale so it isn't a good overview in the first place.
-Anonymous
Send us your feedback. Letters may be edited for length and clarity. Please provide full name, location, and, if applicable, title, and company. dndj@sys-con.com
Related Links:
Subscribe to .NET Developer's Journal Email News Alerts
Subscribe via RSS
