At 12:08 AM 10/30/2005 -0700, you wrote:
>Jacob Kjome wrote:
>> I am quite lost trying to figure out how to write BCel code to match the
>> disassembled code. Can you help out? Here's javap's output for the
>> static block in question...
>
>I am happy to help, but i'm not happy to do your work for you when it
>appears you haven't really put much effort into doing it yourself.
I understand where you are coming from. I've felt the same way with others
when working on several open source projects upon which I am a
committer. However, in this case I'm coming from the user's point of view
and I'm learning to empathize. I've put hours into staring at this stuff
trying to make sense of it and what I've posted so far is as far as I've
gotten with something that doesn't simply die at runtime, so I think you
are being a bit presumptuous here. And, to be honest, my goal here is not
to learn the ins and outs of BCEL, but to get this little tiny piece of
code working so I can move on with life and never bother with this
gobbledygook again (no offense to those who like to write bytecode, it just
not my cup of tea). Like I said, I've got the class working 99%
properly. It seems that this 1% is taking many times the effort it took to
do the first 99%.
> A good place to start learning how to write bcel code is here:
>
>http://jakarta.apache.org/bcel/manual.html
>
>you may be particularly interested in 3.3.4, which talks about
>instruction lists. (almost) all you have to do is write code that
>creates an instruction list and adds to it one instruction per
>instruction in the disassembly of the asm2 code. you can learn about
>instructions, their arguments, and how to generate them by reading the
>bcel manual referenced above.
>
I've seen these docs and they make slightly more sense once I figured out
what the heck the "javap" command provides. What I finally ended up doing
was regenerating the class entirely using the BCELifier. Took me a while
to get it working. It was failing for a couple different reasons. First,
it doesn't seem to like JDK1.5-compiled code at all. It just bombs and
produces no output. Second, it didn't like my ASM2-generated class even
when compiled using JDK1.4.2. It just bombs like the first case. Not sure
why? The VM likes it just fine and the decompiler likes it just
fine. Anyway, I finally compiled the original class using JDK1.4.2 (the
one in which I ran the ASMifier upon) and ran BCELifier upon that. It
worked fine and now I have it all working, with a few tweaks to make it
generalized.
>i'll be happy to take a look at any more specific questions you may have.
I really don't have the first clue about this stuff and am happy to have
the code generated for me. But just for giggles, how about this...
The instruction lists append stuff and return instruction
handles. Great. But if this appending is akin to something like a
StringBuffer, order matters. Is that the case with Instruction lists? If
so, how do I deal with this?...
...
4: ifnonnull 32
...
32: putstatic #47; //Field XMLC_GENERATED_CLASS:Ljava/lang/Class;
...
So, If I'm going in order, how do I reference InstructionHandle 32 before I
create it? for instance...
...
il.append(InstructionFactory.createBranchInstruction(Constants.IFNONNULL,
ih_32));
...
InstructionHandle ih_32 = il.append(_factory.createFieldAccess(className,
"XMLC_GENERATED_CLASS",
new ObjectType("java.lang.Class"), Constants.PUTSTATIC));
...
I must be missing some mind-bogglingly obvious here. Please point it out,
if you could.
thanks,
Jake
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
