On Thu,  7 Jun 2001 08:23, you wrote:
>   - I have no publicly available host that I can dump source code
>     for people to download from.
if you need one for this sort of thing in future drop me a line and I might 
be able to provide a temporary hosting of something.


> 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

Content-Type: Application/Octet-stream; charset="us-ascii"; 
Content-Transfer-Encoding: BASE64

Reply via email to