This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Forte should either include a decompiler module, or the ability to call an external decompiler, such that when you have a class selected in the explorer or object browser, it is possible to choose "Decompile..." from the tools menu and view the decompiled source of the class in the source editor. (and optionally save it from there.) There are a couple of open source Java decompilers, but all seem to be under the GPL, so the calling an external program approach may be best. JODE (http://jode.sourceforge.net/) seems to be a good one, there are a number of them linked from http://dmoz.org/Computers/Programming/Languages/Java/Development_Tools/Translato rs/Decompilers_and_Disassemblers/
Target milestone -> 3.3.1.
*** Issue 18609 has been marked as a duplicate of this issue. ***
Similar thing suggested as #18609; marking as duplicate, but see the other issue, too, when evaluating/implementing.
Cleaning up
Kevin, take a look at jasm module (http://jasm.netbeans.org)
Target milestone was changed from not determined to TBD
http://jode.sourceforge.net: "The bytecode package and the core decompiler is now under GNU Lesser General Public License, so you can integrate it in your project" #define your_project NetBeans I think it could be cool & simple feature for NB 4.0.
Here is a nice decompiler that could be integrated with NetBeans (it already has an Eclipse integration): http://java.decompiler.free.fr/ This feature is now getting more important with annotation processors that generate bytecode, such as Lombok: http://projectlombok.org/. With Lombok, I would like to sometimes see what code was generated, as it does not directly correspond to the original source code.
>Here is a nice decompiler that could be integrated with NetBeans (it already >has an Eclipse integration): http://java.decompiler.free.fr/ It's a C++ code => platform specific => problem to distribute.
You are right; there could be several ways around it: - distribute all binaries for all platforms - place the module on the update center, and the user would get the correct binaries based on her platform - do not bundle anything, but on the first usage of the decompiler (e.g. after double-clicking a .class file), prompt the user to enter the location where she installed the decompiler for her platform (this dialog should also contain a link to the download page).
Added disassembler on the element level as Idea has. There is also SPI BinaryElementOpen allowing plugging of other disassemblers, if time permits I will add an impl for http://java.decompiler.free.fr/ to contrib. Anyway it will not help with lombok as it has associated source through SFBQ which has much higher priority and the disassembler is the last fallback. Fixed in jet-main c63032b4b06b
Integrated into 'main-golden', will be available in build *201002230200* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/c63032b4b06b User: Tomas Zezula <tzezula@netbeans.org> Log: #17309:NetBeans should be able to use a decompiler