Hacker News Reader

Thanks for your response.

What I get from this is that the processor arch. Is dictated by the compiler at compile time, and by writing to bytecode directly we are skipping this.

I thought the proc. arch. was established by the manufacturer and was unavoidably implemented by the jni at runtime... unless there is an interface on top of the jn-interface to deal with the proc. But it seems absurd... why do this at compile time?

View on HN

The JVM is a native-code application (i.e., running on the processor directly) that executes the bytecode by interpreting it (starts fast, but runs slowly) and/or converting it into native code and running that code on the processor directly (delayed by the conversion step, but then runs fast). The latter step, translating bytecode to native code, is known as the just-in-time (JIT) compiler.

So somewhat confusingly, Java typically involves two compilers: one from source code to bytecode, the other from bytecode to native code. By nature, the first is processor-independent, the second is processor-dependent. The second happens at runtime on the target machine — thus, “write once, run anywhere”.

Reply on news.ycombinator.com