Programs are commonly written in Java and compiled to bytecode for the Java virtual machine, which is then translated to Dalvik bytecode and stored in .dex (Dalvik EXecutable) and .odex (Optimized Dalvik EXecutable) files, giving rise to the related terms odex and de-odex. The compact Dalvik Executable format is designed for systems that are constrained in terms of memory and processor speed.
A tool called dx is used to convert some (but not all) Java .class files into the .dex format. Multiple classes are included in a single .dex file. Duplicate strings and other constants used in multiple class files are included only once in the .dex output to conserve space. Java bytecode is also converted into an alternative instruction set used by the Dalvik VM. An uncompressed .dex file is typically a few percent smaller in size than a compressed.jar (Java Archive) derived from the same .class files.
Standard Java bytecode executes 8-bit stack instructions. Local variables must be copied to or from the operand stack by separate instructions. Dalvik instead uses its own 16-bit instruction set that works directly on local variables. The local variable is commonly picked by a 4-bit 'virtual register' field. This lowers Dalvik's instruction count and raises its interpreter speed.
Moreover, according to Google, the design of Dalvik permits a device to run multiple instances of the VM efficiently.
Generally, stack-based machines must use instructions to load data on the stack and manipulate that data, and, thus, require more instructions than register machines to implement the same high level code, but the instructions in a register machine must encode the source and destination registers and, therefore, tend to be larger. This difference is primarily of importance to VM interpreters for which opcode dispatch tends to be expensive along with other factors similarly relevant to just-in-time compilation.
In 2012, academic benchmarks confirmed the factor of 3 between HotSpot and Dalvik on the same Android board, also noting that Dalvik code was not smaller than Hotspot.
Furthermore, benchmarks performed on Android device still show (as of March 2014) up to a factor 100 between native applications and a Dalvik application on the same Android device.[original research?][improper synthesis?] Upon running benchmarks using the early interpreter of 2009, both JNI and native code showed an order of magnitude speed up.
Dalvik is published under the terms of the Apache License 2.0. Google says that Dalvik is a clean-room implementation rather than a development on top of a standard Java runtime, which would mean it does not inherit copyright-based license restrictions from either the standard-edition or open-source-edition Java runtimes.Oracle and some reviewers dispute this.
On August 12, 2010, Oracle, which acquired Sun Microsystems in April 2009 and therefore owns the rights to Java, sued Google over claimed infringement of copyrights and patents. Oracle alleged that Google, in developing Android, knowingly, directly and repeatedly infringed Oracle's Java-related intellectual property. In May 2012, the jury in this case found that Google did not infringe on Oracle's patents, and the trial judge ruled that the structure of the Java APIs used by Google was not copyrightable. The parties agreed to zero dollars in statutory damages for 9 lines of copied code.
On May 9, 2014, the Federal Circuit partially reversed the district court ruling, ruling in Oracle's favor on the copyrightability issue, and remanding the issue of fair use back to the district court.
^Vandette, Bob (2010-11-22). "Java SE Embedded Performance Versus Android 2.2". Oracle Corporation. Retrieved 2011-09-04. "The results show that although Androids new JIT is an improvement over its interpreter only implementation, Android is still lagging behind the performance of our Hotspot enabled Java SE Embedded. As you can see from the above results, Java SE Embedded can execute Java bytecodes from 2 to 3 times faster than Android 2.2."
^"Developing and Benchmarking Native Linux Applications on Android". Lecture Notes of the Institute for Computer Sciences, Social Informatics and Telecommunications Engineering. Springer Publishing. 2009-04-29. Retrieved 2014-03-23. "The results show that native C applications can be up to 30 times as fast as an identical algorithm running in Dalvik VM. Java applications can become a speed-up of up to 10 times if utilizing JNI."
^Ed Bott (September 8, 2011). "The real history of Java and Android, as told by Google". ZDNet. Retrieved 2011-11-27. "The definition of a “clean room” implementation is that the engineers writing the code have no direct exposure to the original, copyrighted material, including code, specifications, and other documentation. That’s a problem for Google, as I noted in yesterday’s post, because there is substantial evidence that the engineers working on the project had direct access to the copyrighted material. "
^Adam Outler (May 16, 2012). "Update on the Oracle Versus Google Trial". Retrieved 2013-01-18. "A major portion of the Oracle’s claims are based on 9 lines of code contained within Java.Util.Arrays.rangeCheck(). Here is the code in question:..."