 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / October 2007Endianness of Java Virtual Machine
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 On Oct 30, 5:05 pm, karthikbalaguru <karthikbalagur...@gmail.com> wrote: > Hi, > Is 'Java Virtual Machine' Big-Endian ? [quoted text clipped - 6 lines] > 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. > On Oct 30, 5:05 pm, karthikbalaguru <karthikbalagur...@gmail.com> > wrote: [quoted text clipped - 17 lines] > 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 karthikbalaguru wrote On 10/30/07 17:30,: >>On Oct 30, 5:05 pm, karthikbalaguru <karthikbalagur...@gmail.com> >>wrote: [quoted text clipped - 26 lines] > 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.  SignatureEric.Sosman@sun.com On Oct 30, 2:30 pm, karthikbalaguru <karthikbalagur...@gmail.com> wrote: > > On Oct 30, 5:05 pm, karthikbalaguru <karthikbalagur...@gmail.com> > > wrote: [quoted text clipped - 25 lines] > 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. On Tue, 30 Oct 2007 14:30:58 -0700, karthikbalaguru <karthikbalaguru79@gmail.com> wrote, quoted or indirectly quoted someone who said : >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. SignatureRoedy Green Canadian Mind Products The Java Glossary http://mindprod.com On Oct 30, 5:05 pm, karthikbalaguru <karthikbalagur...@gmail.com> wrote: > Hi, > Is 'Java Virtual Machine' Big-Endian ? [quoted text clipped - 6 lines] > 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. > Hi, > Is 'Java Virtual Machine' Big-Endian ? [quoted text clipped - 6 lines] > 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. SignatureBeware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth On Tue, 30 Oct 2007 14:05:25 -0700, karthikbalaguru <karthikbalaguru79@gmail.com> wrote, quoted or indirectly quoted someone who said : >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. SignatureRoedy Green Canadian Mind Products The Java Glossary http://mindprod.com > 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. On 31 Oct 2007 06:39:54 GMT, Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> wrote, quoted or indirectly quoted someone who said : >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. SignatureRoedy Green Canadian Mind Products The Java Glossary http://mindprod.com Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.