I plan to post this on the JDE's Contributed Software page. Interested JDE
users can download it from there.
- Paul
At 08:23 AM 6/7/2001 +1000, Craig McGeachie wrote:
>Here it is, on the off chance that anyone else may want to play with
>it. I have attached the file directly, rather than providing a
>download link, because:
> - it's smaller than some of the messages that appear on this list
> - I have no publicly available host that I can dump source code
> for people to download from.
>
>This is a elisp package that will detect that Emacs has opened a
>class file, run the class data through a decompiler, and then replace
>the class data in the buffer with a Java source representation. The
>package can optionally create an editable buffer, constructing a
>.java based name from the original .class based name, that is easily
>saved to disk.
>
>To use, place decompile.el somewhere on your elisp path. Place
>(require 'decompile) in your .emacs file.
>
>The package is intended to be used with Jad, but if you have another
>decompiler that obeys various assumptions built into decompile.el,
>then you should be able to use it by changing the executable name and
>command line option customisation variables.
>
>With a fair degree of chutzpah, I have parented the customisation
>group under the main JDE group.
>
>The source is originally based on a package that was written by Ingo
>Koch, but I have modified it somewhat. Note that the comments
>identify Ingo as the maintainer. I'm not sure how accurate this is
>given that while the structure is much the same, I have almost
>completely rewritten everything.
>
>It is not as complete as I would like. Things that I would like to
>do, or see done (hint hint), are:
> - The package assumes the byte comes from a .class file on
> disk and therefore the .java buffer name can be constructed
> from this. The byte code should be decompiled, and the
> .java buffer name constructed by parsing the source for the
> class declaration.
> - The package demands that the decompiler output source code to
> standard out. This should be made more flexible.
> - There is a flag that, if set, means that the source code is placed
> in a buffer that is modifable, associated with a Java filename,
> and marked as modified. The buffer isn't saved, so the Java file
> isn't written to. The flag should be extended to include a third
> option to automatically save the reconstructed Java source.
> Some thought is needed, about what to do if the intended Java file
> already exists.
> - I wish the programming style was less imperative, and more
> functional, by it's been a while, and my Lisp skills are rusty.
> - I've seen another package that links with jar and zip files to
> automatically view Java source representations of the contained
> files. When I have time, I'll steal the idea and put it here.
>-----------------+---------------------------------------------------
>Craig McGeachie | #include <cheesy_tag.h>
>+61 (410) 774902 | while (!inebriated) c2h5oh = (++bottle)->contents;
>-----------------+---------------------------------------------------
>The following section of this message contains a file attachment
>prepared for transmission using the Internet MIME message format.
>If you are using Pegasus Mail, or any another MIME-compliant system,
>you should be able to save it or view it from within your mailer.
>If you cannot, please ask your system administrator for assistance.
>
> ---- File information -----------
> File: decompile.el.gz
> Date: 7 Jun 2001, 7:49
> Size: 2516 bytes.
> Type: Unknown
