Mark Lewis <mark.lewis@mir3.com> writes:
>> > public void SendInteger4(int val) throws IOException
>> > {
>> > SendChar((val >> 24)&255);
>> > SendChar((val >> 16)&255);
>> > SendChar((val >> 8)&255);
>> > SendChar(val&255);
>> > }
>>
>> This code is like copied/pasted from the JDK:
>>
>> * @since JDK1.0
>> DataOutputStream#writeInt()
>>
>>
>> Any reason for duplicating it in the driver?
>
> Well, in the general case you can only use DataOutputStream's writeInt()
> method if everything is in big-endian byte order, which is true in this
> case but not universally so.
My point is that it IS universally true in the Java universe AND in
the networking universe. There simply cannot be two opposed networking
universes... that would mean we'd have two Internets for instance?
So I think the whole point of Java is that everything is big-endian, so
you do not need to know about endianness anymore. IMHO this is a
success.
> Here it IS big-endian, so the choice is between duplicating one
> method a few lines long, or wrapping the main OutputStream in an
> extra DataOutputStream which would only be used when writing
> big-endian integers. Not sure if one solution is better than the
> other.
OK you can bypass/copy-paste some JDK code for performance
reasons. But then you can not honestly complain Java does a poor job
of hiding endianness when you fiddled with the machine internals
instead of safely staying outside.
Moreover you don't really need to think about endianness when simply
copy/pasting this code.
> It's in the java.nio stuff, look at the javadoc for
> ByteBuffer.order() for a starting point.
Interesting. Looks like you need this only when dealing with
badly-behaved applications that do not use the network order, right?
Should be very seldom, don't you think?
Thanks for answering.