Kotlin seems to be the way that this is moving, especially with Kotlin being added to IntelliJ IDEA 15 [1]. I would imagine that Kotlin support would be built into Android Studio soon.

[1] - https://blog.jetbrains.com/idea/2015/11/intellij-idea-15-rel...

Given they don't have a JVM, I don't think anything makes adopting a JVM language easier.

Kotlin already runs on android as well as groovy

JVM- and Android-targeted Kotlin were built in simultaneously, whereas Android-targeted Groovy was added on last year as an afterthought, so the QA aspects of each will likely be very different. Also, the full-time developer working on Groovy's Android codebase was retrenched last year, whereas Jetbrains is still supporting Kotlin's Android codebase.

I think that's pretty disingenuous. Just because they don't call it Java doesn't mean they don't have a JVM.

It's not being disingenuous: by definition, a JVM has to execute Java bytecode, Android's toolchain merely uses Java bytecode as an intermediate representation. Dalvik VM =/= JVM, insisting it is because the source code was written in Java and/or transitioned through Java bytecode is being disingenuous. It would aslo imply Linux a JVM because GCJ[1] can compile Java bytecode to (Linux) executables.

1. https://gcc.gnu.org/java/

No it doesn't. As long as the language compiles to DEX bytecode the ART compiler and runtime can execute it. The JVM and ART VM are very different and don't even use similar architectures. I should also remind you that Oracle tried to sue Google in regards to VM IP and lost spectacularly so your claim that the old Dalvik VM and JVM are similar and any differences are just trying to split hairs is erroneous.

I suggest you look into the ART runtime. It's not a JVM. For starters it's register based and compiles DEX bytecode into native code.

Not implementing the JVM spec means it's not a JVM. It's that simple.

OK but you're straying into pedantry. They have their own VM which runs bytecode generated by a translation layer. The only language supported by that translation layer is JVM bytecode. Therefore, they effectively have an implementation of the JVM.

> OK but you're straying into pedantry.

You are stripping words of their meaning. There is a precise definition of what JVM means. ART isn't close to that and doesn't try to do that. There's nothing wrong with that, just don't call it a JVM.

You can translate Java into JavaScript and run it on a JavaScript VM. This doesn't make that JavaScript VM a JVM.

Pointing out that a language isn't Java simply because it has curly braces isn't straying into pedantry. Pointing out that something isn't ice simply because it is solid isn't straying into pedantry.

> And there's really no way that you can claim the language used for Android development is not Java.

Even if the language used for Android development is were Java that wouldn't make ART a JVM. JVM is a VM specification that is not tied to the source but the byte code. In several cases (eg. method lookup) there a significant differences between Java and JVM semantics.

The language used for Android development is not Java. Again, there is a precise definition of what Java means (the language specification) and a test to verify what you have is Java (the TCK). ART/Android does not pass that test (it's not even close) and has no intention of doing so. For example Java semantics allow on the fly code generation. AFAIK ART/Android does not support this.

It's clear you don't understand how the ART VM works so why not research it instead of trying to argue how you think it works.

Actually ART runs DEX bytecode not JVM bytecode so I'd argue it's not a JVM at all. By your definition anything that can translate Java to an intermediate representation is a JVM. Does that make LLVM a JVM?

https://llvm.org/svn/llvm-project/java/trunk/docs/java-front...

No, but ART's sole purpose is to run JVM translated programs. If you had another fm that run Java and other languages, you could argue that it is A JVM, but it is also a fm for what ever the language it runs.

I am guessing Oracle's lawyers will argue that is indeed the case. Let's hope they do not prevail

They lost that argument against Google already.

I would argue who is being pedantic. They have a Java SDK so of course they're going to have a JVM bytecode->DEX bytecode translator, but that doesn't mean their VM is even remotely close to a JVM as they don't even share the same architecture.

You couldn't be more wrong. The ART VM processes DEX bytecode and it is not compatible with JVM bytecode. They also use different architectures.

Are you trying to say that the Java language isn't being used to write Android apps?

No, I'm saying the relevance of Java ends at the source level. When the app is converted to DEX bytecode and then compiled to native code there is no dependency on the language or JVM as you seem to think.

There clearly is, otherwise Google would have been able to update to Java 8 on Android by now.

No, the reason Google isn't going to update to Java 8 is due to the litigation from Oracle. Google will likely transition to a new language so why invest time and money upgrading to a language they're going to abandon soon.

Java is not exactly Oracle's territory.

Swift and Objective-C are Apple's territory if Java is Oracle's territory. Besides they are more like no-languages than programming languages. There is a huge number of Java programmers out there compared to Kotlin or some other "it is so cool" language.

No, the safest bet is Eclipse Xtend - http://www.eclipse.org/xtend/ - which compiles to Java.

If they get serious about Flutter (http://flutter.io/) they have a non JVM path forward.