How 256 Java bytecodes are translated to all java files (graphics, IO, etc.)

There is no byte code to open a port or draw graphics on the screen. There are classes that perform these tasks. These classes have methods of their own, they are methods written in C (or any other language that can be compiled into a native library), and because they are native, they can access your operating system's network and graphics libraries to accomplish these tasks. Thus, you create these classes and call some of their methods. Java Bytecode provides bytecode for instantiating classes and for invoking methods on objects. If the JVM sees that it is a native method, it will invoke native code belonging to that method, and that native code can do almost anything a C or C ++ program can do.

So, for example, if you call System.out.println

in Java, something like this happens:

System

is a class with a static variable out

. This variable points to an object of a type java.io.PrintStream

that was already created by the JVM before your method main

is executed. The variable is out

initialized like this:

FileOutputStream fdOut = new FileOutputStream(FileDescriptor.out);
setOut0(new PrintStream(new BufferedOutputStream(fdOut, 128), true));

      

        
        
        
      

    

And the setOut0 method is defined as

private static native void setOut0(PrintStream out);

      

        
        
        
      

    

This means that setOut0 is a native method written in C or some other language that can be compiled and linked against the native library, although at least the interface between Java and this library is usually written in C.

Java will search all loaded libraries for a symbol (in this case, symbol means the name of a function) with a name Java_java_lang_System_setOut0

, this is what Java_ClassName_MethodName

calls it. The sample C code I found for this method looks like this:

JNIEXPORT void JNICALL
Java_java_lang_System_setOut0(JNIEnv *env, jclass cla, jobject stream)
{
    jfieldID fid =
        (*env)->GetStaticFieldID(env,cla,"out","Ljava/io/PrintStream;");
    if (fid == 0)
        return;
    (*env)->SetStaticObjectField(env,cla,fid,stream);
}

      

        
        
        
      

    

But this is not real magic, real magic happens elsewhere. PrintStream.write()

calls BufferedWriter.write()

. This method is called again OutputStreamWriter.write()

(not directly, but sooner or later it ends there) and this method is called StreamEncoder.write()

. Wow, it's hard to trace this call. StreamEncoder

calls BufferedOutputStream.write()

, this call calls FileOutputStream.write()

, and this call calls FileOutputStream.writeBytes()

and finally we are finally there! FileOutputStream.writeBytes()

is a native method. It will look something like this:

JNIEXPORT void JNICALL
Java_java_io_FileOutputStream_writeBytes(JNIEnv *env,
    jobject this, jbyteArray bytes, jint off, jint len) {
    writeBytes(env, this, bytes, off, len, fos_fd);
}

      

        
        
        
      

    

So it calls a function called writeBytes and this function looks different depending on your operating system, for example. be it Windows, Linux or OS X. On UNIX / Linux systems, this function can call another function (and so on), but somewhere it is a simple call to a C function to write something to a C stream FILE *

or file descriptor (which is just a int

to C). Thus, it can be a call printf()/fprintf()

or puts()/fputs()

, which records the call, stdout

or write()

which records on STDOUT_FILENO

. On Windows, this is usually a call WriteFile()

, although it can also be printf()/fprintf()

(these are standard C functions, all platforms should support them).