cp-tools-discuss
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Cp-tools-discuss] gnu.bytecode


From: Elliott Hughes
Subject: Re: [Cp-tools-discuss] gnu.bytecode
Date: Sun, 30 Jan 2005 13:14:18 -0800

On Jan 29, 2005, at 20:34, C. Brian Jones wrote:

On Thu, 2004-12-30 at 01:36, C. Brian Jones wrote:
On Wed, 2004-12-29 at 22:57, Elliott Hughes wrote:
is this the right/a sensible place to talk about gnu.bytecode?

i know there's *a* copy of gnu.bytecode in the repository, but i know
it's not *the* copy. for some reason, it was easier to find this list
than any equivalent kawa one.

i've been writing a tool similar to javap/jcf-dump, but which outputs
something in a form suitable for re-assembly into a .class file. aside
from the lack of support for 1.5 changes, i've found that the
LocalVariableTable support doesn't work (try
gnu.classpath.tools.JavapMain or gnu.bytecode.dump on a class compiled with "javac -g" to see). there's a really simple fix for JavapMain and my disassembler, but i don't know if it'll break kawa or anything else
that uses gnu.bytecode.

is this where i'd find people who're interested?

I wanted to reply again because Tom has mentioned adding an option to
javap to output in a format recognizable by Jasmin, see
http://jasmin.sourceforge.net/.  I've not yet dug into it to determine
if this project is up to date enough to support 1.5 features.

it's not. it also doesn't support the generation of invalid class files, which would seem like one of the uses of a Java assembler.

I've removed gnu.bytecode from the cp-tools CVS in favor of the version
in Kawa CVS.  Here are a few of the things I think need fixing in
gnu.bytecode...

a) Remove use of Class.forName(), if it exists, and substitute in
something that can search a specified path instead.
b) Support 1.5
c) Ensure API provides enough information to output all details of the
class file without using a Writer which may not output in a format you
desire and tends to have special access to internal variables...

i think a better choice is to make the writer methods public and non-final. i fear the other way duplication lies.

Do you want to work on something to output in jasmin format together?

can do. i think that the class i already posted shows there's some mileage in this idea; its output is way easier to read than javap's.

i'm not sure we should worry too much about using exactly jasmin format, though. for one thing, it doesn't support everything we need, and for another, it seems offensively over-complicated for such a simple job. (i have a semi-irrational dislike of JavaCC.)

--
http://www.jessies.org/~enh/





reply via email to

[Prev in Thread] Current Thread [Next in Thread]