Java virtual machine
The JVM reference implementation is developed by the OpenJDK project as open source code and includes a JIT compiler called HotSpot.
More complex than just emulating bytecode is compatibly and efficiently implementing the Java core API that must be mapped to each host operating system.
JRuby and Jython are perhaps the most well-known ports of existing languages, i.e. Ruby and Python respectively.
Of the new languages that have been created from scratch to compile to Java bytecode, Clojure, Groovy, Scala and Kotlin may be the most popular ones.
A notable feature with the JVM languages is that they are compatible with each other, so that, for example, Scala libraries can be used with Java programs and vice versa.
This feature is developed within the Da Vinci Machine project whose mission is to extend the JVM so that it supports languages other than Java.
[10][11] A basic philosophy of Java is that it is inherently safe from the standpoint that no user program can crash the host machine or otherwise interfere inappropriately with other operations on the host machine, and that it is possible to protect certain methods and data structures belonging to trusted code from access or corruption by untrusted code executing within the same JVM.
Furthermore, common programmer errors that often led to data corruption or unpredictable behavior such as accessing off the end of an array or using an uninitialized pointer are not allowed to occur.
Several features of Java combine to provide this safety, including the class model, the garbage-collected heap, and the verifier.
In fact, code verification makes the JVM different from a classic stack architecture, of which efficient emulation with a JIT compiler is more complicated and typically carried out by a slower interpreter.
[13] In many aspects the HotSpot Interpreter can be considered a JIT compiler rather than a true interpreter, meaning the stack architecture that the bytecode targets is not actually used in the implementation, but merely a specification for the intermediate representation that can well be implemented in a register based architecture.
Another instance of a stack architecture being merely a specification and implemented in a register based virtual machine is the Common Language Runtime.
[14] The original specification for the bytecode verifier used natural language that was incomplete or incorrect in some respects.
It will also be possible to optimize the JVM by skipping unnecessary safety checks, if the application being run is proven to be safe.
It assumes the code is "semantically" correct, that is, it successfully passed the (formal) bytecode verifier process, materialized by a tool, possibly off-board the virtual machine.
As an addition to the bytecode verification process, publishers can purchase a certificate with which to digitally sign applets as safe, giving them permission to ask the user to break out of the sandbox and access the local file system, clipboard, execute external pieces of software, or network.
Formal proof of bytecode verifiers have been done by the Javacard industry (Formal Development of an Embedded Verifier for Java Card Byte Code[16]) For each hardware architecture a different Java bytecode interpreter is needed.
This problem is mitigated by just-in-time (JIT) compilers for executing Java bytecode.
A JIT compiler may translate Java bytecode into native machine language while executing the program.
For browsers with the plug-in installed, the applet is allowed to draw into a rectangular region on the page assigned to it.
[20] Since May 2016, JavaPoly allows users to import unmodified Java libraries, and invoke them directly from JavaScript.
The main JVM bytecode to JavaScript transpilers are TeaVM,[22] the compiler contained in Dragome Web SDK,[23] Bck2Brwsr,[24] and j2js-compiler.
