Hacker News Reader

Comment by gsnedders | Hacker News Reader

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.

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.

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.

> 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.

They're not stripping anything of it's meaning; they're taking things to their logical conclusion. And there's really no way that you can claim the language used for Android development is not Java.

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.

I know how it works. Claiming that someone who disagrees with you must not know how something works doesn't exactly prove your point.

> 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.

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.

They're using the Java language. Therefore, something which interprets bytecode coming from it is a java virtual machine. It's that simple.

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.

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/

I'd say that it simply has to execute something coming from Java code. Which both Dalvik and ART do.

I think claiming that Dalvik VM and JVM are so different when they both run stuff coming from Java is just trying to split hairs.

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.

Reply on news.ycombinator.com