Java Big Endian to Linux Little Endian problems

[marknvicf]

I have read a bit about the endian differences, got a couple of jar/libs to help (Android and com.mindprod), but still am not sure how to fix this program that I have (written in JDK 1.4 by someone else who is not here anymore). I have some complicated structures in this program that I don't know how to fix. I have fixed DataInputStream and DataOutputStrea m but using com.mindprod and now have LEDataInput and Output Streams (Little Endian). The purpose is to talk over sockets to a Linux program which is Little Endian, from a Java App which is BigEndian. The structures that I am not sure what to do with are (showing imports): java.io.InputSt ream, java.io.OutputS tream, toByteArray(), java.io.ByteArr ayOutputStream, java.io.ByteArr ayOutputStream, java.io.ObjectI nputStream, java.io.ObjectO utputStream. The program was elegantly written, very complicated, and I am not sure what is going to take more time. Fixing this to talk to Linux (LE), or re-writing parts of it with some of the new stuff in JDK 1.6, Android, etc. Anyone have any suggestions?

[JosAH]

A DataOutputStrea m always writes its data in big endian format. A DataInputStream always reads data in big endian format. If you couple the two streams between two machines there should be no problem at all. If your Linux box expects the data on the wire to be in little endian format don't use a DataOutputStrea m to write to the wire.

kind regards,

Jos

[marknvicf]

Well, not using DataInput or DataOutputStrea ms means a rewrite of a large and complicated program. In any case com.mindprod has LE versions of those. It's all the others in this program that cause all the problems.

Let me be clear: the Java program was originally developed to run on Solaris(Unix) and communicate with programs(call them simulator programs) on the same - and all are Big Endian. However, there has been a movement thru my company to replace Unix boxes with Linux ones, and the simulator programs have been migrated to Linux, but no one payed attention to the endianness problems. So, I am stuck with BE java not being able to communicate with LE Linux simulators. This also leaves me with a number of streaming formats that don't have LE replacements like DataInput & OutputStreams.

So I am still left wonder what to do.

[JosAH]

Aren't all those simulator programs (running on those LE Linux boxes now) written using Java? If not I guess your best option is to use that LEDataOutputStr eam to send the data over in little endian format so your Linux (Intel?) boxes can read and understand the data.

Also you might look at the IntBuffer and ByteOrder classes although I don't know of any out-of-the-box solution right now; I'll think about it.

kind regards,

Jos

[marknvicf]

No, the simulators are written in ADA. They are unchangeable for all intents and purposes. The communication between the java and ada is on two separate sockets with very different formats.Fixing this problem is not as simple as I first thought as I have found inconsistent results when trying various standard coding methods such as swapping bytes etc.

I think this is going to take a while.

[JosAH]

I bet these ADA programs write binary data back to that Java module? Right? And they write it back in LE form? Can I conclude that all your binary data communication must be done in LE form?

kind regards,

Jos

[marknvicf]

Yes, you can quite safely say that the data is binary and the Java must use LE binary data methods.

Thanks for helping. If you have any ideas let me know. All the work I've done has only produced inconsistent results so far.

[JosAH]

@marknvicf
If you can change the Java part of it all you can do the following:

1) find the file src.zip in your JDK installation and extract the files DataOutputStrea m.java and DataInputStream .java

2) Change the writeX and readX methods to their little endian equivalents; this is easy to do when you see the code of the original mehods: change the methods that write/read chars/shorts/ints and longs.

3) Rename the files to LEDataOutputStr eam.java and LEDataInputStre am.java and put them in another package.

4) Everywhere in your Java code use the two new classes (see above) instead of the original classes.

That should do the job ...

kind regards,

Jos

[marknvicf]

Jos,

Ok, first let me say that the ADA is in Linux on an Intel machine. The Java is on a PC, but I move the jar file to a location on the linux. Ok, here it is. One, there will not be funding to fix the foobar ADA code since they never gave thought to such things as I am encountering now. Everything was great when the ADA was on Unix(Solaris 8) on Unix boxes.

What I am encountering now makes simple endian conversion look like simple math compared to chaos theory. The bit streams are coming over in unknown formats and while I have been able to fix the headers that contain information about the data, I have not been able to fix the data. Simply put, and another extremely intelligent guy at work agrees with me, I would have to convert each packet of data differently (by packet I just mean each short or int or whatever). The overhead would kill the program by slowing it down to a crawl. That doesn't include the method by which the data and handshaking go back and forth. This has to do with the first socket which contains a type of information (can't tell anything about it - proprietary). The second I have had some actual success with as it is completely different from the first one, but still have some bugs to work out.

Endianess has gone from black box to simple as pie, on its own. I could write endian code all day in my sleep now. Too bad this problem is so screwy. I may just tackle the ADA side myself and looking into things like lhost etc. It's better to ask forgiveness than permission has been my motto for, oh, about 26 professional years now.

My aforementioned friend from work said that if I fix this problem, people all over the world will thank me. I think that is just geek talk for getting a white paper out of it.

thanks for all your previous help,

Mark