How exactly does JVM differ from Dalvik and/or ART?

Question

Firstly, I think I may have titled this question poorly, but I couldn't think of the right words, so please, feel free to suggest an edit and I will make it, so that the question is more educational and relevant to others.

I know that javax.Swing simply cannot be used for an Android project, and I've accepted this and learned Android XML based UI design, but just out of curiosity, I want to know exactly why.

I realize that the screen dimensions of a phone might be something Swing wouldn't handle well, but what is to stop a developer from simply importing the javax.Swing package (besides Android Studio simply not letting it happen in the first place), however deformed and hideous Swing windows might be on an Android device screen? I also realize that AWT and SWT would also have to be imported, but the same question applies to these packages as well.

I think my lack of understanding of this might really root from a lack of understanding of how the Java Virtual Machine and the Android equivalent (is Dalvik still used, or have they switched cold-turkey to ART?).

As always, any information or reading on the subject you can provide is greatly appreciated. I really want to learn more about the fundamentals of how the JVM, Dalvik, and ART work.

Docile

differents between Dalvik/ART and JVM has nothing to do with lack of javax.Swing or other part of the standard Java in android framework – Wilford

Right, but what is to stop a developer from simply importing them? Why, fundamentally, will they not work on the Android platform? – Docile

Answer 1

There are at least three fundamental differences:

• the APIs differ; for instance, even the most recent versions of Android's SDK don't have JSR 203;
• the binary formats differ; Dalvik/ART does not generate JVM bytecode;
• the language level differs; it is partly a consequence of the previous point, since in order to support a given language level, Dalvik/ART has to reimplement all the parsing/bytecode production to fit its own VM.

The latter point means that as a result, there is still no mainstream support in Android of try-with-resources which appeared in Java 5 years ago; various efforts have seen the day to support this plus Java 8's "goodies" over time, but none of them is really Java "at the core"; understand, they do not use the JVM, they do not use the Java compiler.

Recent news tells that this is bound to change in "Android N" (which will actually use OpenJDK). Which is good news. Also, as to point 1, you may recall that infamous Oracle vs Google case with regards to APIs being copyrightable... This is still not completely settled.

Brunner

+1, especially for the 3rd point. So the reason you can't import certain packages is that the virtual machine can't parse/translate pieces of it into the appropriate bytecode? Also, what is try-with-resources? – Docile

Well, JVM bytecode and Dalvik/ART are fundamentally incompatible; maybe some machinery exists to translate, I'm not aware of such a project however. As to try-with-resources, see here for a brief tutorial. – Brunner

That's very interesting, I can't believe I've never seen that before. I can think of so many times that would have been useful to me in various projects. – Docile

"Dalvik/ART does not generate JVM bytecode;" this sentence is very confusing IMO. Correct me if I'm wrong but the runtime(dalvik/art) does not generate bytecode, the compiler does. The runtime consumes it and JIT or AOT compiles it into machine code. – Montiel

Answer 2

This article might be helpful to you http://www.techentice.com/dalvik-vs-art-android-drop-dalvik-efficient-art/ although, it is somewhat outdated, ALREADY. It does, however explain differences between JVM and DALVIK and ART.

Groenendael

Thank you for this, very interesting article. +1 – Docile