reading & writing binaries(.class files)

You're much better off using a library, such as BCEL or ASM to read and write to class files.

If you're having trouble simply opening up a binary file, then disassembling a class file is too advanced for you.

Here's the class file format...

http://java.sun.com/docs/books/jvms/second_edition/html/ClassFile.doc.html#74353

regards,

Owen

omcgoverna at 2007-7-11 23:12:18 >

>Did anybody say anything about disassembling?

He wants to read and write class files, it's the title of the post.

I don't appreciate you dismissing my suggestions like that.

There's plenty of gotchas in reading and writing class files, such as Longs & Doubles taking up 2 positions in the constant pool.

Hence the reason why I suggested using an open source library like BCEL or ASM. These are still valid as class readers, even if you don't touch the byte code. ( disassembly )

But what would I know Ejp....sure I only wrote my own Java 1.5 class reader / disassembler.

omcgoverna at 2007-7-11 23:12:18 >

Ejp, you haven't contributed anything constructive to this post.

The OP wants to read and write class files.

I gave him the class file format link, essential for the task.

I also suggested the use of certain open source libraries if he doesn't want to reinvent the wheel.

Those libraries can be used as simple class readers ( what the OP wants to do ), or disassemblers for more advanced stuff.

Sometimes posters appreciate a broader answer, than just

"use java.io.DataInputStream".

omcgoverna at 2007-7-11 23:12:18 >

So you've read the file, maybe reading it with a FileInputStream, and storing it in an array of bytes, or writing it to a ByteArrayOutputStream ?

After that you should have a nice array of bytes.

You cannot translate that array of bytes into a string directly.

This is because not all byte sequences are valid unicode character codes.So a random byte array of 0x24, 0x35, 0x44, 0x12 may not make a valid string. In fact, Java tends to change any unknown characters into "?".

So, if you "really" must store binary data into a string, you would typically encode it, either as a hex string, or using Base64 encoding.

Then you send that encoded string.

The receiver decodes it, and that decoding process recreates the binary byte array.

Alternatively, maybe you can just "send" the byte array directly ?

regards,

Owen

omcgoverna at 2007-7-21 19:52:05 >

> Ejp, you haven't contributed anything

> constructive to this post.

>

> The OP wants to read and write class files.

> I gave him the class file format link, essential for

> the task.

> I also suggested the use of certain open source

> libraries if he doesn't want to reinvent the wheel.

>

> Those libraries can be used as simple class readers (

> what the OP wants to do ), or disassemblers for more

> advanced stuff.

>

> Sometimes posters appreciate a broader answer, than

> just

> "use java.io.DataInputStream".

Ok. But that isn't what ejp nor I interpreted OP ask asking.

And in fact the last post by the OP suggests that our interpretation is correct - the OP just wants to copy files. And thus the fact that they are class files is irrelevant.

So if you wish to post a more complete solution on how to copy files now is your chance.

jschella at 2007-7-21 19:52:05 >

> And in fact the last post by the OP suggests that our

> interpretation is correct - the OP just wants to copy

> files. And thus the fact that they are class files

> is irrelevant.

i don't think it is irrelevant because i have to load the class files after writing them. i may be wrong.

> So if you wish to post a more complete solution on

> how to copy files now is your chance.

i have been able to copy the files and need no complete solution. its just that i haven't been able to load the copied class files due to the classFormatError

Ralf_Pa at 2007-7-21 19:52:05 >

> You wouldn't normally use bcel to load a class. The

> VM does that for you.

i have a written a customized file loader which works fine in normal cases. it doesn't work for this case where i'm trying to write the class file.

> And that tells you that the class file (that you

> copied) is just wrong. (Noting that bcel isn't going

> to help with that.)

that is exactly what i'm trying to figure out :-) (how to copy it correct)

thanks

Ralf_Pa at 2007-7-21 19:52:05 >

> Ejp, you haven't contributed anything

> constructive to this post.

That would just makes us even at best. There is nothing constructive about irrelevance. There is arguably something positive about pointing out irrelevance and keeping the discussion on-topic.

And there is nothing that is even logical about appealing to yourself as an authority.

ejpa at 2007-7-21 19:52:10 >

If that refers to this thread I don't think that any of it applies actually. The OP said he wanted to read and write .class files, and that's the question that got answered, and not by anybody making any assumptions. The people that did the assuming were the people who made the mistakes actually.

Personally I think it's more educational, and therefore ultimately more helpful and useful, to answer the question that is being asked. It may well turn out to be the wrong question, but that's educational too. If I don't understand the question I generally ask for more information rather than make assumptions. Assumptions cause bugs. A large part of this job is learning to ask the right question, or learning how to discover what the right question really is, and learning how to narrow the focus, and identify and reject false assumptions, until the answer appears.

ejpa at 2007-7-21 19:52:10 >

> But as a novice(without any experience in Java file

> handling), i didn't know that a class file cannot be

> directly sent as a string (and that was a

> requirement). how would it strike a novice to use

> BASE 64 encoding?

It's good you have a solution to this problem, but let me just point out that the requirement for sending binary data as a string is, um, to put it politely, unusual. All of the standard methods for transferring files just copy the files, byte by byte, from source to target. Converting from format A to format B, transmitting, and converting from format B to format A is just an invitation for things to go wrong.

I am sure you were just given these requirements and didn't think them up yourself. I just wanted to make sure you didn't think they were the world's best requirements and that when you get around to designing such things you don't do that.

DrClapa at 2007-7-21 19:52:10 >