Endianness of Java Virtual Machine

[karthikbalaguru]

Hi,
Is 'Java Virtual Machine' Big-Endian ?
Or
Is it independent of Endianness ? (That is Bi-Endian)

Can someone provide some link in the internet that discusses
more about this ?

Thx in advans,
Karthik Balaguru

 

[dalouis]

Hi,
Is 'Java Virtual Machine' Big-Endian ?
Or
Is it independent of Endianness ? (That is Bi-Endian)

Can someone provide some link in the internet that discusses
more about this ?

Thx in advans,
Karthik Balaguru

Endian is something that is determined by the architecture of the
machine you are running on, therefore it would depend which platform
you are running the virtual machine on.

Although Im not sure what difference it would make for you if you are
writing java code, since java completely hides details such as this
from you.

 

[dalouis]

Hi,
Is 'Java Virtual Machine' Big-Endian ?
Or
Is it independent of Endianness ? (That is Bi-Endian)

Can someone provide some link in the internet that discusses
more about this ?

Thx in advans,
Karthik Balaguru

Endian is something that is determined by the architecture of the
machine you are running on, therefore it would depend which platform
you are running the virtual machine on.

Although Im not sure what difference it would make for you if you are
writing java code, since java completely hides details such as this
from you.

 

[Joshua Cranmer]

Hi,
Is 'Java Virtual Machine' Big-Endian ?
Or
Is it independent of Endianness ? (That is Bi-Endian)

Can someone provide some link in the internet that discusses
more about this ?

Thx in advans,
Karthik Balaguru

Java is big-endian insofar as its Data{In,Out}putStream assumes
big-endianness and the class file specification is big-endian. From most
developers' standpoints, it is endian-agnostic.

 

[karthikbalaguru]

Endian is something that is determined by the architecture of the
machine you are running on, therefore it would depend which platform
you are running the virtual machine on.

Although Im not sure what difference it would make for you if you are
writing java code, since java completely hides details such as this
from you.

Actually, I came across a link that states 'Java Virtual Machine is of
Big-Endian'.
http://www.intel.com/design/intarch/papers/endian.pdf

I am eager to know the advantages of such a desing of Java Virtual
Machine.
Is there any link / document in the internet that discusses about
these ?

Thx in advans,
Karthik Balaguru

 

[Roedy Green]

Is 'Java Virtual Machine' Big-Endian ?
Or
Is it independent of Endianness ? (That is Bi-Endian)

Can someone provide some link in the internet that discusses
more about this ?

see http://mindprod.com/jgloss/endian.html

Java is designed so the machine internally could be either. You can't
write a program to tell. However, any DataOutputStream will be big
endian.

 

[Eric Sosman]

karthikbalaguru wrote On 10/30/07 17:30,:

Actually, I came across a link that states 'Java Virtual Machine is of
Big-Endian'.
http://www.intel.com/design/intarch/papers/endian.pdf

I am eager to know the advantages of such a desing of Java Virtual
Machine.
Is there any link / document in the internet that discusses about
these ?

The fact that a document makes a claim doesn't prove
that the claim is correct ...

It seems to me that Intel's characterization of the
JVM as Big-Endian is at best incomplete. The endianness
of the JVM is unspecified, and implementations for both
Big-Endian and Little-Endian machines do in fact use the
platforms' native formats for `int' and so forth. You
could point to a specific JVM implementation and say that
it was Big- or Little- or Middle-Endian, but saying that
"the JVM" has a specific endianness is like saying C++ has
a specific endianness.

It is true that the class file format is Big-Endian,
serialized forms are Big-Endian, and so on. But these are
best viewed as interchange formats, not as characteristics
of the JVM's that process them. Your computer -- whatever
it is -- presumably sends and receives IP packets, whose
format has a strong Big-Endian flavor; does it follow that
your computer is Big-Endian? Of course not, and it seems
equally pointless to point to a Big-Endian class file and
infer that any JVM that loads it must be Big-Endian.

 

[Owen Jacobson]

Actually, I came across a link that states 'Java Virtual Machine is of
Big-Endian'.http://www.intel.com/design/intarch/papers/endian.pdf

I am eager to know the advantages of such a desing of Java Virtual
Machine.
Is there any link / document in the internet that discusses about
these ?

Since Java doesn't expose the representation of its primitive types
(which is one of two primary applications of endianness), it's
impossible to tell from examining the behaviour of code which way
around the bytes are stored in memory from within Java. This means
that the JVM is free to use whatever order is faster on the computer
it's running on: on LE machines (like the x86 architecture), that'll
be little-end-first; on BE machines (like the PowerPC), that would be
big-end-first.

However, Java's IO toolkit originally only provided ways to produce
external representations (the *other* primary application of
endianness, and the one the IBM whitepaper is probably referring to)
in big-endian form. Since big-end-first is the standard network byte
order for integer representation (see the POSIX htonl/htons
functions), this made sense at the time. The NIO framework includes
support for mixed- and little-endian IO.

 

[Roedy Green]

I am eager to know the advantages of such a desing of Java Virtual
Machine.

That is not quite true. What is true that Java when it talks to the
outside world always uses big endian. Inside it can be anything.
Unlike C, external files have a precise standard bit representation.
This makes it much easier to share files between different platforms
and different applications.

 

[Andreas Leitgeb]

Is 'Java Virtual Machine' Big-Endian ?
Or
Is it independent of Endianness ? (That is Bi-Endian)

There are already lots of answers, and I will add one,
that would let you find out the endianess of your
particular JVM, but it takes some java bytecode
knowledge:

Write a java program that defines an integer variable,
with value 0xaabbccdd, and assign it (with cast) to
a short and a byte variable, which you have written
out to System.out.
Then you compile it, and it would write (always, inde-
pendent on endianess) the values for 0xccdd and 0xdd.

Now comes the tricky part:
in the bytecode there exist instructions to convert the
intvalue to a byte/short-value, and you'd have to modify
the class file(*) to do some noop's instead of these
converting instructions. after that you run the code
again, and see if the result has changed.
I haven't tried it myself, but my prediction is, that
on little-endian platform the result would stay the same,
whereas on big-endian platforms it would change to 0xaabb
and 0xaa.

(*) with help of sun's "javap" (to check the results)
you could try+error your way there, or you could
use some disassembler (not a decompiler!) and
assembler.

 

[Roedy Green]

Now comes the tricky part:
in the bytecode there exist instructions to convert the
intvalue to a byte/short-value, and you'd have to modify
the class file(*) to do some noop's instead of these
converting instructions. after that you run the code
again, and see if the result has changed.

Just want to clarify here. A careless reader might get the erroneous
idea the compiler generates different byte code depending on whether
the target were big on little endian. Definitely not so. The same byte
code is used on all platforms. The byte code does the same logical
thing on all platforms. It is just the JVM has different amounts of
work to implement each byte code on different platforms. Your trick
exploits this.