5 ms·

What do you mean by "compatible with the JVM"? Android is compatible with the JVM. Android's dx tool converts the JVM bytecode in your JAR files to Dalvik/ART c

by DCKing 12y ago

What do you mean by "compatible with the JVM"? Android is compatible with the JVM. Android's dx tool converts the JVM bytecode in your JAR files to Dalvik/ART compatible DEX files. You probably mean that is not compatible with all parts of Oracle Java. You can make Android apps using Scala, Kotlin, and Clojure. To my knowledge can use the 'native' build tools for Scala (SBT) and Clojure (Leiningen) already. I'm building an Android app using Scala libraries of which the authors never even thought about running it in an environment as alien as Android. So yeah, I think that the door is open already. What is still lacking is official support for better languages than Java. That would be great.

pjmlp 12y ago
Those are based on hacks with slower execution and bulkier APKs as the Java tooling.
- smrtinsert 12y ago
  They're not based on hacks.
  - pjmlp 12y ago
    Until they are packaged in a single "Android Support" package instead of being scattered across multiple project sites that one needs to manually glue together without Google sponsorship[1], they are hacks. [1] At least Oracle sponsors alternative JVM languages.
- eloisant 12y ago
  At least for Scala it's not based on hacks, it's not slower and the reason the APKs are bulkier is because if you don't use proguard you'll be embedding the whole Scala library. It's not specific to Android, the only difference is that on Android we care about the whole package size while on a server it's not a problem. Groovy is probably slower, but it's slower on a regular JVM as well. So nothing specific to Android here.
  - pjmlp 12y ago
    How come it is not hacks? I have to download plugins from multiple sources, compile them if the binaries for the latest release aren't available, glue everything together and hope for the best while coding and deploying to Android. Not to mention the bugs while interacting both with Eclipse and Android Studio tooling.

by DCKing 12y ago

pjmlp 12y ago

Those are based on hacks with slower execution and bulkier APKs as the Java tooling.

smrtinsert 12y ago
They're not based on hacks.
- pjmlp 12y ago
  Until they are packaged in a single "Android Support" package instead of being scattered across multiple project sites that one needs to manually glue together without Google sponsorship[1], they are hacks. [1] At least Oracle sponsors alternative JVM languages.
eloisant 12y ago
At least for Scala it's not based on hacks, it's not slower and the reason the APKs are bulkier is because if you don't use proguard you'll be embedding the whole Scala library. It's not specific to Android, the only difference is that on Android we care about the whole package size while on a server it's not a problem. Groovy is probably slower, but it's slower on a regular JVM as well. So nothing specific to Android here.
- pjmlp 12y ago
  How come it is not hacks? I have to download plugins from multiple sources, compile them if the binaries for the latest release aren't available, glue everything together and hope for the best while coding and deploying to Android. Not to mention the bugs while interacting both with Eclipse and Android Studio tooling.