java virtual machine is big endin processor

After my lecture give a introduction to the java GUI application I
goes
home and write a program , and I just disassemble it ,

The program source code is shown in here ... anyway , the java
language compiler
pushes the line numbers as the debugging symbols into the binary
executable .But
I redundant my some comments and line spacings , so this program may
be vary
when you considering the lines . Please don't try to compare the
lines .
Shuch as .line21 , is a line number debugging symbol information .

----------------------------------------------------------------------
package guifirstlesson ;

import java.awt.* ;

public class GUIFirst extends Frame {
        // the constructor of this class
        public GUIFirst (){
                super ("This was an basic GUI example ");

        }

        // This is our faviourate main method that everyone knows how
to
write
        public static void main ( String args[] ){

                // creates an object of the GUIFirst class
                GUIFirst guiFirst = new GUIFirst ();

                // then make it's size
                guiFirst.setSize ( 300, 500 );

                // then display that on the screen
                guiFirst.setVisible (true );
        }

}

----------------------------------------------------------------------

what are you think about this , this is the dissembly listing that I
was get a screenshot of the currently working IDA pro .

[img]
<img src="http://img90.imageshack.us/img90/6826/
firstprogramdisassemblyrm4.gif"/>

http://img90.imageshack.us/img90/6826/firstprogramdisassemblyrm4.gif

The best thing of this is that the , I learn that java virtual
machine
is a completely
a big edin processor . Just see that these instructions ,

        sipush 300
        sipush 500
        invokevirtual guifirstlesson/GUIFirst.setSize(II)V

These java assembly langauge instructions are relevant to the hex
machine code

        11 01 2C 11 01 F4 B6 00 05

anyway I don't know the java assembly language , But I was guessed
the
op code
relevant to the sipush is 11 , guess that !

Yes the java language is using the stack for the parameater passing
for the line
of code that I above written .

 guiFirst.setSize ( 300, 500 );

The 300 is pushed first it's hex value is 0x12C and when comes to the
500 it's
hex value is 0x1F4 , likewise the instruction 11H is the opcode for
the instruction
for the java virtual machine .

So it makes me to think that the JVM is an big endin virtual
processor .

and I learn many things form this ,
        1. Java used the big ending type to strore the variables in
it's
memory .
        2. Java byte code can sometime have the debugging line number
information
           as the form of symbols .
        3. Looking at the dissassembly you can easily reverseenginner
into
your
           orginal java program .
        4. java is imports vm libraries by using the dynamic linking ,
it was
similar to
           a win32 dll program that imports the functions and
datastructures
using the
           import table . Runtime class loading I don't know the
mechanism
anyway .
        5. Java language is heavily vulnnualble to the reverse
engneering .

what are you think about this , friends . Please let me know your
ideas . Please .

java byte code is fun than java source code , I like java byte code
than java
source codez ! .

anyway this is java byte code . what about Native win32 or win64 or
the linux byte codes
.. You will be feel funny with it . Get Addicted !

If you need more information about debuggers and disassemblers ,
please ask here .

                                                -- sanzilla jackcat -