Hacker News Reader

Comment by Mithaldu | Hacker News Reader

Is there any chance of Java 8 support landing anytime soon?

Google is probably very wary of going more into Oracle territory.

Given Android's adoption at this point, if I were Google's management, I'd adopt another JVM language. Sort of Objective-C -> Swift. Kotlin would probably the safest bet from an "easy adoption" point of view.

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/

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.

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.

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.

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

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

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.

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.

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.

Give Kotlin a try. I have great experiences with the language on both mobile and server development. Don't miss Java 8 a bit when I do server development in Kotlin.

As appealing as Kotlin can be, many of us are only allowed to use platform languages on customer projects.

Hence why Google's silence on the language support is so irritating.

I could do without another Android Studio release, if they provided an open roadmap for Android for whatever language they think on supporting going forward. Instead of pure silence.

As it is, we will be using Java 10 on the desktop, server and IoT devices, when they eventually remember to let us know of a new platform language.

Yes. There are loads of commits in the Jack and ART repositories of AOSP relating to Java 8 features like lambdas, method references, and default methods.

I'd expect them to come with the next release of Android (since they require new VM bytecode instructions), with a possible official back-port tool similar to Retrolambda.

Considering Google's friendly relationship with Jetbrains (Android Studio) I'm more likely to believe that they will just make Kotlin an official language.

I don't think so. In order for that to happen, Google would need to support new bytecodes in their JVM (Dalvik? I forget), which would be a backwards-incompatible change. So unfortunately I don't expect to see Java 8 in Android for quite a while.

Dalvik has been replaced by ART (the Android Run Time) in 5.0 Lollipop. Dalvik was the JIT compiler in 4.4 and below, and with 5.0+, ART is an ahead-of-time compiler.

There's still lots of Dalvik based devices in use.

http://developer.android.com/about/dashboards/index.html

They still could let us choose, no?

You already have to choose between Java 7 and target only 4.4 onwards devices or use Java 6 to be able to target older devices.

They could have released Marshmallow with Java 8 support, so that in the same way one could choose to target 6.0 devices and newer or not.

Reply on news.ycombinator.com