My understanding is that Google didn’t like Oracle’s licensing policy for using the JRE in Java ME so it just rewrote it using its own JVM specification that mimics the JRE but behaves a little bit differently, especially when it comes to making things more efficient and more secure.
So, if my understanding is correct, it means that when javac is ran on some Java source code and compiled into “binary”
byetcode, a compliant JVM will interpret that bytecode different than Dalvik will (in some cases). This is the inherent
difference between Dalvik and other (compliant) JVMs.
If anything I have said so far is incorrect, please begin by correcting me!
Now, if Android came with its own compiler (which it might), and compiled Java source in a different (Dalvik-compliant)
manner than javac, then I could understand how some code (not compiled with the Android SDK) would not run on an
Android device:
MySource.java --> javac --> MySource.class (JRE-compliant) --> JVM --> running Java app MySource.java --> android-compiler --> MySource.class (Dalvik-compliant) --> Dalvik JVM --> running Android app
However, it looks like you use javac to compile Android apps!?!? So it looks like we have this:
MySource.java --> javac --> MySource.class (JRE-compliant) --> JVM --> running Java app MySource.java --> javac --> MySource.class (JRE-compliant) --> Dalvik JVM --> running Android app (???)
If javac is used to compile all sources into bytecode, then why is it that Dalvik can’t run some types
of Java code?
I asked a very similar question yesterday and although it was technically answered (after re-reading my question I see I was simply not specific enough) no one was able to explain what it is that’s inherent to Dalvik that makes it impossible to run Java code from projects like Google Guice or Apache Camel. I was told that in order to get Camel to run on Dalvik, that I would have to get Camel’s source and then it would have to be “built with the Android SDK”, but I couldn’t get clarity on what that meant or implied.
With Camel, for instance, you have this (simplified):
RouteBuilder.java --> javac --> RouteBuilder.class --> jartool --> camel-context-2.9.jar --> JVM --> running Camel ESB RouteBuilder.java --> javac --> RouteBuilder.class --> jartool --> camel-context-2.9.jar --> Dalvik JVM --> doesn't work !!! (???)
Clearly, something is happening inside the Dalvik JVM that prevents it from running certain types of Java code. I’m trying to understand what types of Java code will not run when “fed” into the Dalvik JVM.
Edit: In before “but Camel 3.0 will run on Android!” I know – not my question!
Advertisement
Answer
I’m trying to understand what types of Java code will not run when “fed” into the Dalvik JVM.
Dalvik JVM differs from other JVMs in following aspects:
It uses special DEX format for storing applications binaries vs. JAR and Pack200 formats used by standard Java virtual machines. Google claims that DEX results in smaller binaries than JAR. I think they could use Pack200 with the same success, but they decided to go their own way in this aspect
Dalvik JVM was optimized for running multiple JVM processes simultaneously
Dalvik JVM uses register-based architecture vs. stack based architecture of other JVMs with intent to speed up execution and to reduce binary sizes
It uses its own instructions set (not a standard JVM bytecode)
One can run (if needed) several independent Android applications within a single JVM process
Application execution can span across several Dalvik JVM processes “naturally”. To support this it adds:
Special object serialization mechanism based on Parcel and Parcelable classes. Functionally it serves the same purpose as standard Java Serializable, but results in smaller data footprint and is potentially more lenient towards differences in versions of classes
Special Android way to execute inter process calls (IPC) based on Android Interface Definition Language (AIDL)
Until Android 2.2 Dalvik JVM did not support JIT compilation which adversely impacted Android application performance. Adding it in 2.2 improves markedly execution speed for often used applications