Hi folks,

I don't know what prompted the choice to use big-endian
storage of numbers in Java, since I've always found little-endian
more intuitive, but I would really appreciate it if you
put a little-endian-read into the stream classes of 
java.io.  This would obviate a lot of the byte-swapping
I've had to do up to now, and make my life easier (and some
other people's lives, judging by the discussion forums).

It could be an ease of use issue, also, because there
are a lot of developers who don't understand the whole
big-endian and little-endian issue and can't grasp why
every time they read a Windows file into Java they
get a garbled mess.

Sincerely,
Marc S. Casalaina
(Review ID: 18606)
======================================================================

======================================================================

This functionality is offered in java.nio. Buffers can be filled with bytes from many sources and then examined as if they contain primitives in either byte order.
 xxxxx@xxxxx  2002-05-09

Our workaround was to copy the DataInputStream source code to create a
LittleEndianDataInputStream class.  However, I also need little-endian support
in the RandomAccessFile class, and there's no easy workaround for that.  If
these classes didn't have final methods, we could simply subclass them.

this would be useful for me too

Things start to become worse as of jdk1.2, because
now the docs of DataInput require that all input
is big-endian, so that it is no longer allowed to
write a class which implements DataInput and
reads little-endian. 
Please note that between the invention of the wheel
and Java there have been other things, in
particular software which wrote data in 
little-endian.

This 'big' endian,  'little' endian has been a curse 
for me...I did the obvious, switched the bytes, but it did not give expected
result. If anyone has a nice work-a-around please advise....I need it 
NOW. 

To pifpafpuf:
Thanks for pointing that out.  I was unaware of the JDK 1.2 changes in the
DataInput and DataOutput interfaces.  I think it's a huge mistake to require
big-endian implementations of those interfaces.  Why should the interfaces
require anything from the underlying implementations?
It's bad enough that the DataInputStream and DataOutputStream implementations
only support big-endian data.  At least we can modify the source code to
support little-endian data.  But with the new restrictions on DataInput and
DataOutput, we can't write *any* implementations that work with little-endian
data -- unless we ignore those restrictions.

I'm working with a file format which actually specifies a combination of big
and little endian bytes within the file.  Anything which made this easy to deal
with would be worthwhile.  Implementing the operation at the lowest level would
also cut down on the operational overhead of performing byte-swapping before
using the data.

While I disagree with the original posters comments that 
little-endian is more intuitive. (I find Big-endian to be 
much easier to deal with.)  I agree that methods should be 
provided to read and write both ways.  I also agree with 
the decision to force Big-endian on DataInput and 
DataOutput.  This must be done to preserve compatibility of 
those APIs. Having DataInput do something arbitrary would 
break everything.  Writing the implementations that xorxor 
describes is exactly what they are trying to prevent.  If 
you want that level of little-endian support then a new 
little-endian interface is required that always does things 
the little-endian way. I would be settle for methods added 
to the Integer class, etc. that would do a quick byte swap.

What?!  What possible reason could DataInput/DataOutput have
for specifying the byte order being written?  Their job is
to take higher-level entities like ints and floats and
"serialize" them to a byte stream.  The manner in which that
byte stream is structured should be up to the specific
implementation of DataInput/DataOutput.  How else are we
supposed to be compatible with non-Java data streams??!  Not
everything is a byte swap... what about reading VAX format
floats, for example?

That's the whole point.  Having DataInputStream and 
DataOutputStream work defferently depending on the 
implementation would mean that the two streams could not 
talk to each other across platforms - totally 
unacceptable.  The format (e.g. VAX floats) should be 
explicite.  Perhaps this could work like the character 
encodings?  So the format can be specified.  It is too late 
to change the default behaviour though.