Re: Decompiler elisp connector
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 >+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
Re: Decompiler elisp connector
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. cheers dim > > 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 > +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"; name="decompile.el.gz" Content-Transfer-Encoding: BASE64 Content-Description:
Decompiler elisp connector
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
+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
decompile.el.gz
