Recommended Free Tools
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Java JVM vs DVM is not a current two-way Android choice: the JVM runs JVM bytecode for Java SE, while Dalvik was Android’s former runtime for DEX bytecode. Android replaced Dalvik with ART as the default runtime in Android 5.0, API level 21, so new Android apps target ART, not DVM.
The comparison still matters because it explains why Android uses .dex files instead of ordinary JVM .class files, why Android applications are not simply desktop Java applications, and how Android’s runtime evolved.
Key takeaways
- The JVM is an abstract machine specified by the Java Virtual Machine Specification; individual JVM implementations may interpret bytecode or compile it with JIT, AOT, or a combination of techniques.
- Dalvik was Android’s original managed runtime and executed register-based Dalvik Executable (DEX) bytecode rather than ordinary JVM class files.
- Dalvik gained a trace-based JIT compiler in Android 2.2, API level 8, while ART appeared as an alternative in Android 4.4, API level 19, and became Android’s default runtime in Android 5.0, API level 21.
- Modern Android still uses DEX as its application bytecode format, but ART—not Dalvik—executes that bytecode on current Android versions.
- Use a standard JVM for Java SE, server, desktop, cloud, or other JVM-hosted applications; target Android ART for applications packaged as APKs or app bundles.
What is the JVM?
The Java Virtual Machine, or JVM, is a specified abstract machine that loads, verifies, and executes Java class files. The Java Virtual Machine Specification defines the class-file format, instruction set, loading and linking rules, runtime data areas, verification, exception behavior, and execution model.
The JVM is not one specific program. HotSpot, OpenJ9, GraalVM-based runtimes, and other implementations can make different decisions about interpretation, just-in-time (JIT) compilation, ahead-of-time (AOT) compilation, garbage collection, and optimization. Consequently, statements such as “the JVM always uses JIT” or “the JVM always pauses for garbage collection” are too broad.
A conventional Java workflow looks like this:
Java source
↓ javac
JVM class files (.class)
↓ JARs, modules, or application packages
JVM execution
↓ interpretation and/or JIT/AOT compilation
Native machine instructionsFor example, these standard JDK commands compile and launch a simple Java program:
javac Hello.java
java Hellojavac normally creates Hello.class, and java starts a JVM-based runtime to load and execute that class. Exact behavior depends on the installed JDK and runtime implementation.
Where is the JVM used?
The JVM is designed for general-purpose Java platforms. Common JVM application domains include backend services, enterprise systems, desktop software, application servers, build tools, cloud services, and data-processing systems. JVM-hosted languages also include Kotlin, Scala, Groovy, and Clojure, although each language has its own compilation and library considerations.
Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Repair Windows errors before they cause bigger problemsFix Now →A standard JVM is the natural target when an application depends on Java SE APIs, server frameworks, desktop libraries, JVM deployment tools, or infrastructure such as servers, containers, and cloud platforms. The Java SE specifications describe the broader platform specifications surrounding the JVM.
What was the Dalvik Virtual Machine?
Dalvik, commonly called the Dalvik Virtual Machine or DVM, was Android’s original managed application runtime. Dalvik was designed for mobile devices with tighter memory, storage, and battery constraints than the desktop and server environments traditionally targeted by Java.
Dalvik executed Android’s Dalvik Executable (DEX) bytecode. DEX is distinct from JVM class-file bytecode and uses a register-based instruction model. The Dalvik bytecode documentation describes the bytecode machine model, registers, instructions, and calling conventions.
Dalvik was not simply a smaller or renamed JVM. Dalvik had a different bytecode format, instruction model, library environment, packaging system, optimization strategy, and relationship with Android’s application framework. Android applications historically used Java-language source in many cases, but the source language did not make the Android runtime a conventional Java SE JVM.
Free tools Windows power users keep installed
One-click scans. No signup required.
Why did Android use Dalvik instead of a conventional JVM?
Android used Dalvik because Android needed a runtime and application format designed around mobile-device constraints and Android’s own process and framework model. Android documentation describes DEX as designed for Android and optimized for a minimal memory footprint; that description is a design goal, not proof that Dalvik was universally faster or more memory-efficient than every JVM in every workload.
The relevant engineering pressures included:
- Limited RAM and storage: Early mobile devices had substantially tighter resource budgets than typical servers and desktops.
- Battery constraints: Runtime work, application startup, and compilation had to be considered alongside power consumption.
- Multiple application processes: Android needed application isolation and lifecycle management integrated with its operating-system model.
- Compact application representation: DEX uses a shared file structure intended to reduce duplication across classes and methods.
- Android-specific APIs: Android applications depend on the Android framework, lifecycle, permissions, storage, UI, sensors, and platform services rather than Java SE alone.
Android’s memory guidance also discusses memory mapping and shared or compact representations involving DEX code, optimized files, resources, and native libraries. Those techniques are part of Android’s broader memory system; they should not be reduced to the claim that every application receives a completely independent, full virtual machine with no shared memory. See the Android memory-management overview for the platform context.
What is the difference between JVM and DVM?
The JVM and DVM are both managed runtimes capable of executing Java-derived code, but they target different platforms and do not execute the same application bytecode in the same way.
| Criterion | Standard JVM | Dalvik / Android |
|---|---|---|
| Primary target | Java SE and other general-purpose JVM platforms | Android mobile devices and the Android application environment |
| Primary bytecode | JVM class files, commonly .class |
Dalvik Executable files, commonly .dex |
| Instruction model | Stack-based JVM instruction model | Register-based Dalvik instruction model |
| Typical packaging | JARs, modules, and platform-specific application packages | APK or Android App Bundle containing DEX files |
| Libraries and APIs | Java SE or another JVM platform’s libraries | Android framework APIs and Android runtime libraries |
| Compilation strategy | Implementation-dependent: interpretation, JIT, AOT, or combinations | Dalvik used interpretation and later JIT; current Android ART uses interpretation, JIT, AOT, and profile-guided optimization depending on conditions |
| Current status | Central to current Java SE development | Historical Android runtime; ART is the current Android runtime |
| Typical applications | Servers, desktops, enterprise systems, cloud services, and build tools | Older Android applications and legacy or reverse-engineering research |
The stack-versus-register distinction is an architectural difference, not a universal performance ranking. Execution speed depends on the runtime version, compiler, processor, memory system, garbage collector, application workload, and compilation state.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
How do JVM class files and Android DEX files differ?
JVM class files and Android DEX files are different bytecode formats. A Java compiler can initially produce JVM-style class files during an Android build, but Android build tools convert the application’s code into DEX before the code is packaged for the device.
| Stage | Conventional Java application | Android application |
|---|---|---|
| Source | Java source, or another JVM-targeting language | Java or Kotlin source, plus Android resources and manifest data |
| Intermediate output | JVM class files | Build tools may produce JVM-style class files before Android conversion |
| Runtime bytecode | .class files, usually packaged in JARs or modules |
.dex files, packaged in an APK or app bundle |
| Execution environment | JVM and Java SE or another JVM platform | ART and the Android framework |
Android’s platform documentation describes the current build path in which Android build tools compile application code into DEX bytecode. Modern builds commonly use d8 for DEX conversion and may use R8 for shrinking, optimization, and obfuscation. Older Android explanations often mention dx; dx is not the normal current application-build tool.
A simplified modern path is:
Java or Kotlin source
↓ Android Studio and Gradle build tools
D8 conversion
↓
classes.dex
↓
APK or Android App Bundle
↓
ART on the Android device or emulatorDEX was designed to reduce duplication and memory pressure, but DEX is not guaranteed to be smaller than class files in every situation. Final size depends on the application, compression, build tools, multidex configuration, and packaging.
How do stack-based and register-based execution differ?
A stack-based instruction model places operands on an implicit operand stack and consumes those operands when an instruction runs. A register-based model names virtual registers explicitly and uses those registers as instruction inputs and outputs.
Windows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallOutdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchA conceptual stack-based sequence might look like this:
push value 1
push value 2
add top two values
store resultA conceptual register-based sequence might look like this:
move value 1 into register v0
move value 2 into register v1
add v0 and v1 into v2Stack bytecode can be compact and straightforward for compiler output. Register-based instructions can make data flow more explicit and may avoid some push and pop operations, but register operands can require more bits in an instruction. The actual result depends on the interpreter, compiler, processor, memory hierarchy, and workload. Register-based DEX should not be described as automatically faster than every stack-based JVM.
How did Dalvik and ART use interpretation, JIT, and AOT compilation?
Dalvik and ART changed over Android releases, so “Dalvik uses interpretation” and “ART uses AOT” are incomplete descriptions when applied without a version qualifier.
Do these 3 things before closing this tab:
1Scan for outdated or missing drivers - takes under a minute2Repair Windows errors before they cause bigger problems3Fix the driver behind crashes, sound loss and screen glitches| Android/runtime milestone | Execution-model significance |
|---|---|
| Early Dalvik releases | Dalvik primarily interpreted DEX bytecode; later behavior should not be projected backward onto every early release. |
| Android 2.2, API level 8 | Android introduced a trace-based JIT compiler for Dalvik, allowing frequently executed code to be compiled while an application was running. |
| Android 4.4, API level 19 | ART appeared as an alternative runtime alongside Dalvik. |
| Android 5.0, API level 21 | ART became the default Android runtime, replacing Dalvik for normal platform execution. |
| Later and current Android releases | ART uses combinations of interpretation, JIT, AOT, and profile-guided optimization. The precise policy depends on Android version, device state, and compilation profiles. |
The Android runtime documentation explains the Dalvik-to-ART transition and ART’s evolving execution strategies. Android’s documentation on ART verification and compatibility also documents version-sensitive runtime and bytecode-verification behavior.
Rank #3
Modern ART is therefore not accurately described as purely AOT. Early ART emphasized AOT compilation, while later Android releases expanded the use of JIT and profile-guided compilation. JVM implementations likewise use different execution strategies, so JIT-versus-AOT alone does not define the JVM-versus-Dalvik distinction.
What replaced Dalvik on Android?
Android Runtime, or ART, replaced Dalvik. ART was introduced as an alternative in Android 4.4, API level 19, and became the default runtime beginning with Android 5.0, API level 21. ART continues to execute DEX bytecode, so replacing Dalvik did not mean Android switched to ordinary JVM .class execution.
A useful modern description is: ART is Android’s current managed runtime, analogous to a JVM in its role, but distinct from a conventional Java SE JVM in its bytecode format, APIs, packaging, and platform integration.
For normal modern Android development, the practical choice is not “JVM or DVM.” The practical choice is usually a standard JVM for a Java SE or JVM-hosted application, or Android ART for an Android application.
How do memory, processes, and garbage collection compare?
Android historically ran application components in Linux processes with an associated managed runtime environment, supporting application isolation and lifecycle management. The phrase “one VM per app” is a useful approximation, but it is not a complete operating-system description.
- An Android application can be configured to place components in different processes.
- Android can share read-only or memory-mapped data where possible.
- The operating-system process model and the managed runtime instance are related but not identical.
- Modern Android uses ART rather than separate DVM instances.
Both JVM implementations and Android runtimes provide automatic memory management, but garbage-collection behavior varies by implementation and release. HotSpot, OpenJ9, and other JVMs can use different collectors and heap policies. Historical Dalvik collectors also changed, and ART’s collectors and pause behavior are not identical to Dalvik’s.
There is no technically sound universal answer that “DVM has better garbage collection” or “the JVM never pauses.” A meaningful garbage-collection comparison must identify the runtime version, Android or operating-system version, device hardware, application workload, heap configuration, compiler state, and measurement method.
Are JVM and DVM security models the same?
The JVM and Android runtimes both use managed execution and bytecode verification, but a virtual machine alone does not describe Android’s complete security boundary.
JVM bytecode verification is part of the execution model defined by the JVM specification. Android combines runtime checks with Linux process isolation, application identities, permissions, signing, and framework-level controls. ART’s verification and compatibility behavior has also changed across Android versions, as described in the Android ART verification documentation.
Android’s security architecture is therefore broader than “each application runs in a VM.” Process boundaries, operating-system identities, permissions, framework services, and runtime verification all contribute to isolation.
Are Java applications compatible with Android applications?
Java-language compatibility does not guarantee JVM bytecode, library, framework, or package compatibility. A Java program that runs on a desktop JVM may depend on Java SE classes, filesystem behavior, desktop UI libraries, reflection details, native libraries, or JVM-specific features that are unavailable or different on Android.
The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →| Compatibility layer | What must be checked |
|---|---|
| Language compatibility | Whether Java or Kotlin source syntax and language features are supported by the chosen toolchain. |
| Bytecode compatibility | Whether the produced bytecode can be transformed into Android-compatible DEX and accepted by the target Android version. |
| Standard-library compatibility | Whether required Java or Kotlin library classes and methods exist in the Android environment. |
| Framework/API compatibility | Whether the application’s UI, lifecycle, storage, permission, sensor, and platform-service assumptions match Android. |
| Package compatibility | Whether the output is a valid APK or app bundle rather than a standard JVM JAR or module. |
A standard JVM cannot directly run an Android APK as if the APK were a normal JAR. Conversely, an Android runtime cannot be assumed to support every Java SE library or JVM feature. Android build tools can transform, desugar, shrink, optimize, or otherwise adapt code before DEX packaging, but build-time transformation does not make every platform API interchangeable.
Kotlin does not change the central distinction. Kotlin or Java Android source is compiled into Android-compatible DEX and executed by ART; Kotlin source is not evidence that an application targets a standard desktop or server JVM.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.What should developers use today?
The correct runtime depends on the deployment target and platform APIs, not on whether the source code happens to use Java syntax.
| Project requirement | Recommended target | Reason |
|---|---|---|
| Java SE server, desktop, enterprise, or cloud application | Standard JVM | The project needs JVM libraries, Java SE APIs, server tooling, desktop support, or JVM-compatible deployment. |
| Android phone, tablet, TV, Wear OS, or emulator application | Android ART through the Android SDK and build tools | The project uses Android lifecycle, UI, storage, permissions, sensors, or platform services and is packaged as an APK or app bundle. |
| Old Android device or legacy APK investigation | Dalvik knowledge and appropriate legacy tooling | Dalvik remains relevant for historical compatibility, old APKs, DEX/ODEX research, and runtime analysis. |
| Mobile security or reverse-engineering research | DEX and Dalvik/ART analysis tools | The objective is inspection or research rather than selecting a runtime for a new application. |
Do not choose DVM for a new mainstream Android project. Build the application with current Android tooling, produce DEX, and test the result on the Android versions and devices that the application supports.
How can you inspect JVM and Android output?
JVM output can be inspected as class files and JAR contents using JDK or bytecode-analysis tools. Android output can be inspected as APK and DEX contents. Inspection tools are development or reverse-engineering utilities; they are not runtime components.
For an APK, Android SDK tooling may provide commands such as:
apkanalyzer
apkanalyzer dex packages app.apk
apkanalyzer files list app.apkOther commonly used tools include adb, jadx, baksmali, and Android Studio’s APK Analyzer. Exact command availability depends on the installed Android SDK and tool version, and tools differ in purpose and licensing. Use these tools to inspect packages, DEX files, resources, or disassembled code—not to infer that an APK is an ordinary JVM application.
Common misconceptions about JVM and DVM
“DVM is Android’s version of the JVM.”
Dalvik served an analogous managed-runtime role, but it was a separate runtime with DEX bytecode, a register-based instruction model, Android-specific libraries, and Android-specific packaging. Calling Dalvik a conventional JVM hides the differences that matter to developers.
“Android runs Java class files directly.”
Android builds may pass through JVM-style class files, but the Android application package normally contains DEX bytecode. ART executes DEX rather than ordinary JVM class files.
Best Value
“Dalvik always used JIT.”
Dalvik’s execution strategy changed across releases. Android 2.2, API level 8, introduced Dalvik JIT compilation; earlier releases should not be described as though they had the same JIT behavior.
“ART is purely AOT.”
Early ART emphasized AOT compilation, but modern ART uses a combination of interpretation, JIT, AOT, and profile-guided optimization. The precise behavior depends on the Android release, device, and compilation profile.
“One runtime is always faster or uses less memory.”
Universal performance rankings are unsupported without a defined runtime version, device, operating-system version, workload, compilation state, garbage collector, and benchmark method. Architectural goals are not the same as guaranteed benchmark results.
Do these 3 things before closing this tab:
1Fix the driver behind crashes, sound loss and screen glitches2Clear out junk files and repair common Windows errors3Scan for outdated or missing drivers - takes under a minute“Java source automatically runs on Android.”
Java syntax is only one compatibility layer. Android applications also require compatible libraries, Android APIs, packaging, lifecycle behavior, permissions, storage assumptions, and DEX conversion.
Why does the JVM vs DVM comparison still matter?
The JVM vs DVM comparison is partly historical but remains useful for understanding Android’s architecture. The comparison explains the origin of DEX, the difference between stack-based and register-based bytecode, Android’s mobile-focused runtime design, and the transition from Dalvik to ART.
Dalvik is mainly relevant today when studying older Android releases, supporting legacy devices, analyzing old APKs, investigating DEX or ODEX files, researching mobile security, or learning how Android runtime optimization developed. For current Android application execution, ART is the relevant runtime.
Final verdict: JVM, DVM, or ART?
Choose a standard JVM when the target is Java SE, a JVM-based server, desktop application, enterprise system, build tool, or cloud service. Target Android ART when the application is intended for Android and uses Android’s framework, lifecycle, permissions, storage, UI, sensors, or platform services.
Learn Dalvik to understand Android history and legacy bytecode, but do not treat DVM as a current runtime option for a new Android project. The most accurate modern summary is: the JVM runs JVM class-file applications on general-purpose Java platforms; Dalvik was Android’s former DEX runtime; ART is Android’s current DEX runtime.
Frequently Asked Questions
Is DVM the same as JVM?
No. The JVM executes JVM class-file bytecode, while Dalvik executed Android DEX bytecode in a different register-based runtime and library environment. Dalvik served a similar managed-execution purpose but was not simply an Android-branded conventional JVM.
Does modern Android use Dalvik or ART?
Modern Android uses ART, not Dalvik, for normal application execution. ART became Android’s default runtime in Android 5.0, API level 21, and ART continues to execute DEX bytecode.
Can a standard JVM run an Android APK?
No. A standard JVM cannot run an Android APK as though the APK were a normal JAR. Android applications depend on DEX, Android framework APIs, Android packaging, and the Android application lifecycle.
Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Clear out junk files and repair common Windows errorsFree Scan →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Which should I learn for a new Android project: JVM or DVM?
A new Android project should target Android ART through the Android SDK and build tools, not Dalvik. A standard JVM remains the appropriate target for Java SE, server, desktop, enterprise, and other general-purpose JVM applications.
The Bottom Line
Bottom line: The JVM and Dalvik were related managed-runtime concepts, not interchangeable runtimes. The JVM remains central to Java SE, Dalvik is mainly historical, and ART is the current Android runtime that executes DEX bytecode.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
