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

Reply via email to