endian : Java Glossary

Your Options to Solving the Endian Problem: a Summary

In a binary file, there are no separators between fields. The files are in binary, not readable ASCII (American Standard Code for Information Interchange).

What do you do if you want to read data not in this standard format, usually prepared by some non-Java program?

You have five options:

1. Rewrite the export program that is providing the imported file. It might export directly in either big-endian binary DataOutputStream or character DataOutputSream format. See binary formats.
2. Write a separate translator program that reads and rearranges bytes. You could write this in any language.
3. Read the data as bytes and rearrange them on the fly.
4. Use LEDataInputStream, LEDataOutputStream and LERandomAccessFile analogs of DataInputStream, DataOutputStream and RandomAccessFile that work with little-endian binary data. You can read about LEDataStream. You can download the code and source free. You can get help from the File I/O Amanuensis to show you how to use the classes. Just tell it you have little-endian binary data. This is the easiest way.
5. If you are using Java version 1.4 or later, you can use nio and the ByteBuffer. order( ByteOrder. LITTLE_ENDIAN ) technique. This the most efficient way.

You Probably Don’t Even Have a Problem!

Most people new to Java coming from C think that they need to code differently depending on whether the machine they are using internally represents integers as big or little endian. In Java it does not matter. Further, without resorting to native classes, there is no way you can even tell how they are stored. The JVM (Java Virtual Machine) may store them either way internally but Java is cleverly constructed so that it never matters. Java has no struct I/O and no unions or any of the other endian-sensitive language constructs.

The only time endianness becomes a concern is in communicating with legacy little-endian C/C++ applications.

The following code will produce the same result on either a big or little endian machine:

// take 16-bit short apart into two 8-bit bytes.
short x = 0xabcd;

byte high = (byte)(x >>> 8);

byte low = (byte)x;/* cast implies & 0xff */

out.println( "x=" + x + " high=" + high + " low=" + low );

Reading Little-Endian Binary Files

I had to implement routines parallel to those in java.io. DataInputStream which reads raw binary, in my LEDataInputStream and LEDataOutputStream classes. Don’t confuse this with the java.io.DataInput human-readable character-based file-interchange format.

If you wanted to do it yourself, without the overhead of the full LEDataInputStream and LEDataOutputStream classes, here is the basic technique. If you are not familiar with how to fudge unsigned data in java by masking off the high order bits, you might want to read the unsigned and masking entries first.

Reading Little-Endian Shorts

Reading Little-Endian Longs

Reading Little-Endian Chars

Reading Little-Endian Ints

In a similar way to short we handle int.

Reading Little-Endian Doubles

Reading Little-Endian Floats

Reading Little-Endian Bytes

byte readByteLittleEndian( )
   {
   // 1 byte signed -128 .. 127. Nothing special needed in addition.
   return readByte();
   }

Nio and ByteBuffer for handling Little Endian Files

Unicode

History

Those in the big-endian camp (most significant byte stored first) include the Java VM virtual computer, the Java binary file format, the IBM 360 and follow-on mainframes such as the 390 and the Motorola 68K and most mainframes. The Power PC is endian-agnostic.

Blefuscudians (big-endians) assert this is the way God intended integers to be stored, most important part first. At an assembler level fields of mixed positive integers and text can be sorted as if it were one big text field key. Real programmers read hex dumps and big-endian is a lot easier to comprehend.

In the little-endian camp (least significant byte first) are the Intel 8080, 8086, 80286, Pentium and follow ons and the MOS 6502 popularised by the Apple ][.

Lilliputians (little-endians) assert that putting the low order part first is more natural because when you do arithmetic manually, you start at the least significant part and work toward the most significant part. This ordering makes writing multi-precision arithmetic easier since you work up not down. It made implementing 8-bit microprocessors easier. At the assembler level (not in Java ) it also lets you cheat and pass addresses of a 32-bit positive ints to a routine expecting only a 16-bit parameter and still have it work. Real programmers read hex dumps and little-endian is more of a stimulating challenge.

If a machine is word addressable, with no finer addressing supported, the concept of endianness means nothing since words are fetched from RAM (Random Access Memory) in parallel, both ends first.

What Sex Is Your CPU (Central Processing Unit)?

Four Byte Sexes

reverseBytes

Learning More