4 ms·

So what is dalvik?

by wehadfun 13y ago

So what is dalvik?

wmf 13y ago
Dalvik is the JVM[1] in Android. [1] Ignore the pedants saying otherwise; it walks like a duck and quacks like a duck.
- Zigurd 13y ago
  Some people will complain that it is not a JVM at all, since it interprets Dalvik bytecode, not Java bytecode. You must run the Android toolchain, which translates Java bytecodes to Dalvik bytecodes, to produce code that runs on Dalvik.
- eropple 13y ago
  If it actually did walk or quack like a duck, you'd be right--but it doesn't. It does not support the Java bytecode format; this is why Groovy, Rhino/LiveConnect, etc. don't work (and you can't do compile-time weaving, further limiting it). It does not support a recognized class library profile. There is a JVM specification and Dalvik does not conform to it: that means it's not a JVM. It isn't pedantic to say that Dalvik isn't a JVM, because it's not. RoboVM isn't a JVM, either. Supporting Java does not a JVM make.
  - Zigurd 13y ago
    > this is why Groovy, Rhino/LiveConnect, etc. don't work You were doing pretty good up to there. The Android toolchain does not compile to Dalvik bytecode. It translates from Java bytecode to Dalvik bytecode. So any language that compiles to Java bytecode could be used to write Android apps. There are many projects to bring other JVM languages to Android.
    - eropple 13y ago
      I am well aware of how Android's dexer tools work and that non-Java languages work on Dalvik; I use Scala on Android regularly. groovyc builds legal Java bytecode and (as of 2012, at least--since the advent of dexmaker this may have changed) fails when you try to run the dexed output on Android (RTCG). Rhino will work as an embedded runtime on Android with optimizations disabled--in which case it runs in fully interpreted mode--but fails when you enable optimizations or when you attempt to use LiveConnect (runtime class construction). And this is because Dalvik doesn't understand Java bytecode. It's not conformant to either J2SE or J2ME and these are examples of libraries that puke because of its nonconformance. That's all I'm saying.
      - Zigurd 13y ago
        I think you are mixing up a couple things here: Converting JVM languages that result in bytecode sequences that dex or Dalvik would never otherwise see in their test suites could uncover bugs. Since all that is open source, and unlikely to rank high on Google's priorities, the answer is to fix those bugs. Unless you mean to say this somehow falls outside Dalvik's coverage of Java semantics. Other things, like loading Java bytecode dynamically at runtime are limitations of not using Java(TM) bytecode.
        eropple 13y ago
        Perhaps I'm not being clear. Groovy and Rhino emit bytecode that translates to Java at compile-time. Their runtime code generation facilities crash on Dalvik because Dalvik does not support runtime-generated, JVM-compatible code. Dalvik does not support legal J2SE operations because it doesn't support Java bytecode as per the JVM spec. I am not saying that Dalvik is bad. I'm saying it isn't a JVM; I was using this as just one example of its not-JVMness.
        ixampl 13y ago
        Was just wondering... for Groovy couldn't they just bundle the tooling to turn the runtime-generated bytecode into Dalvik bytecode? If there were a reliable Dalvik bytecode to JVM bytecode translator I assume most of the issues (similarly occuring with libraries like Javassist etc.) associated with load time and manipilation and code generation could be resolved. Or are there other special limitations on classloading in Android?
        vorg 13y ago
        > for Groovy couldn't they just bundle the tooling to turn the runtime-generated bytecode into Dalvik bytecode? There's no "just" when it comes to the Codehaus implementation of the Groovy Language. According to the Codehaus Groovy project manager [1], "Groovy is not able to run properly on Google's Android mobile platform ... (It takes) 20 seconds to start up a simple Hello World". BTW, that webpage was seeking students to do work making Groovy run on Android, but Google didn't accept that project, or any projects related to Groovy [2], perhaps because no students were interested or maybe because of Codehaus's history of mishandling GSoC projects. The last Groovy project ever accepted was one in 2011 rewriting Groovy's antiquated parser in Antlr 3.0. The project failed and Google only paid out half the project money. [1] http://groovy.codehaus.org/GSoC+2013 http://groovy.codehaus.org/GSoC+2013 [2] http://www.google-melange.com/gsoc/projects/list/google/gsoc2013 http://www.google-melange.com/gsoc/projects/list/google/gsoc...
- Oletros 13y ago
  Well, Dalvik is register based and JVM is stack based, this is a big difference
loudmax 13y ago
My understanding is pretty limited, so take my explanation with a grain of salt. Dalvik is the virtual machine that runs Android apps, just as the JVM runs Java programs. Android apps are written in Java, compiled to Java bytecode, then converted to Dalvik bytecode.

So what is dalvik?

wmf 13y ago

Dalvik is the JVM[1] in Android. [1] Ignore the pedants saying otherwise; it walks like a duck and quacks like a duck.

Zigurd 13y ago
Some people will complain that it is not a JVM at all, since it interprets Dalvik bytecode, not Java bytecode. You must run the Android toolchain, which translates Java bytecodes to Dalvik bytecodes, to produce code that runs on Dalvik.
eropple 13y ago
If it actually did walk or quack like a duck, you'd be right--but it doesn't. It does not support the Java bytecode format; this is why Groovy, Rhino/LiveConnect, etc. don't work (and you can't do compile-time weaving, further limiting it). It does not support a recognized class library profile. There is a JVM specification and Dalvik does not conform to it: that means it's not a JVM. It isn't pedantic to say that Dalvik isn't a JVM, because it's not. RoboVM isn't a JVM, either. Supporting Java does not a JVM make.
- Zigurd 13y ago
  > this is why Groovy, Rhino/LiveConnect, etc. don't work You were doing pretty good up to there. The Android toolchain does not compile to Dalvik bytecode. It translates from Java bytecode to Dalvik bytecode. So any language that compiles to Java bytecode could be used to write Android apps. There are many projects to bring other JVM languages to Android.
  - eropple 13y ago
    I am well aware of how Android's dexer tools work and that non-Java languages work on Dalvik; I use Scala on Android regularly. groovyc builds legal Java bytecode and (as of 2012, at least--since the advent of dexmaker this may have changed) fails when you try to run the dexed output on Android (RTCG). Rhino will work as an embedded runtime on Android with optimizations disabled--in which case it runs in fully interpreted mode--but fails when you enable optimizations or when you attempt to use LiveConnect (runtime class construction). And this is because Dalvik doesn't understand Java bytecode. It's not conformant to either J2SE or J2ME and these are examples of libraries that puke because of its nonconformance. That's all I'm saying.
    - Zigurd 13y ago
      I think you are mixing up a couple things here: Converting JVM languages that result in bytecode sequences that dex or Dalvik would never otherwise see in their test suites could uncover bugs. Since all that is open source, and unlikely to rank high on Google's priorities, the answer is to fix those bugs. Unless you mean to say this somehow falls outside Dalvik's coverage of Java semantics. Other things, like loading Java bytecode dynamically at runtime are limitations of not using Java(TM) bytecode.
      - eropple 13y ago
        Perhaps I'm not being clear. Groovy and Rhino emit bytecode that translates to Java at compile-time. Their runtime code generation facilities crash on Dalvik because Dalvik does not support runtime-generated, JVM-compatible code. Dalvik does not support legal J2SE operations because it doesn't support Java bytecode as per the JVM spec. I am not saying that Dalvik is bad. I'm saying it isn't a JVM; I was using this as just one example of its not-JVMness.
        ixampl 13y ago
        Was just wondering... for Groovy couldn't they just bundle the tooling to turn the runtime-generated bytecode into Dalvik bytecode? If there were a reliable Dalvik bytecode to JVM bytecode translator I assume most of the issues (similarly occuring with libraries like Javassist etc.) associated with load time and manipilation and code generation could be resolved. Or are there other special limitations on classloading in Android?
        vorg 13y ago
        > for Groovy couldn't they just bundle the tooling to turn the runtime-generated bytecode into Dalvik bytecode? There's no "just" when it comes to the Codehaus implementation of the Groovy Language. According to the Codehaus Groovy project manager [1], "Groovy is not able to run properly on Google's Android mobile platform ... (It takes) 20 seconds to start up a simple Hello World". BTW, that webpage was seeking students to do work making Groovy run on Android, but Google didn't accept that project, or any projects related to Groovy [2], perhaps because no students were interested or maybe because of Codehaus's history of mishandling GSoC projects. The last Groovy project ever accepted was one in 2011 rewriting Groovy's antiquated parser in Antlr 3.0. The project failed and Google only paid out half the project money. [1] http://groovy.codehaus.org/GSoC+2013 http://groovy.codehaus.org/GSoC+2013 [2] http://www.google-melange.com/gsoc/projects/list/google/gsoc2013 http://www.google-melange.com/gsoc/projects/list/google/gsoc...
Oletros 13y ago
Well, Dalvik is register based and JVM is stack based, this is a big difference

loudmax 13y ago

My understanding is pretty limited, so take my explanation with a grain of salt. Dalvik is the virtual machine that runs Android apps, just as the JVM runs Java programs. Android apps are written in Java, compiled to Java bytecode, then converted to Dalvik bytecode.