Hacker News Reader

Comment by maaaats | Hacker News Reader

How come one can use other modern jvm languages on Android, but not newer Java? E.g., if you can make Android support Kotlin, why cannot Java8 be introduced the same way?

View on HN

Kotlin compiles to jvm 1.6 bytecode, so even though it is a different language it runs the same as Java 6 on the devices.

Supporting Java 8 requires updating the vm & OS, which is difficult to do in the Android ecosystem. It may happen in the future but backwards compatability will be tough since the phone manufacturers lag so badly on platform upgrades. I'm not even getting into the Oracle v Google spat that may slow down adoption of a newer version of Java.

For that reason Kotlin is a lot more viable today than Java 8. Maybe someday Java 8 will make it to Android, but that day is definitely not today. Even after it is released in the newest devices, it probably won't be widespread for 18+ months.

edit: no one should downvote the parent question it is a legit technical ask without an obvious answer.

It might be a stupid ask, but: What would it take for Android to start support for a different dev language (being able to write an app in js or Swift for example)? Also, is it never the case that when a new language is released (Java 8 for example) there is usually a strong emphasis on backwards compatibility (compiling into all or a few previous versions' bytecodes)?

You can get Java 6 bytecode from a Java 8 compiler but it will fail to compile if you used Java 8 features:

    $ jdk-1.8-64/bin/javac -target 1.6 -source 1.6 LambdaTest.java 
    warning: [options] bootstrap class path not set in conjunction with -source 1.6
    LambdaTest.java:16: error: lambda expressions are not supported in -source 1.6
        Runnable r2 = () -> System.out.println("Hello world two!");
                         ^
      (use -source 8 or higher to enable lambda expressions)
    1 error
    1 warning

Trying to heed the error:

    $ jdk-1.8-64/bin/javac -target 1.6 -source 8 LambdaTest.java 
    javac: source release 8 requires target release 1.8

Out of curiosity, why would the Android ART VM care about what language version, or language for that matter, was used to create the DEX byte code? As long as the DEX byte code generator is able to convert the original byte code to DEX byte code isn't that all that really matters?

Yes, but the issue with Java 8 is that it requires new bytecode commands (mostly related to handling lambdas and method references) and is thus not compatible with older JVMs.

There is a project that patches Java 8 bytecode and replaces all lambda invocations and method references with anonymous class instantiations. It's called RetroLambda and lets Android devs use Java 8 lambdas in their code. It does open a whole new pit of issues though.

Nobody has made Android support Kotlin. Kotlin compiles to Java 6 bytecode. If someone made a Java 8 source or bytecode to Java 6 bytecode compiler, including support for the changes in the standard library, that would also work, but nobody has done that, so it doesn't.

I'm not sure how much success Android developers are having with this, but Retrolambda combined with streamsupport (java.util.stream) and ThreeTen (java.time) makes Java 8 on Android possible:

https://github.com/orfjackal/retrolambda

Sounds like there might be some things that are missing or incomplete, but having lambdas and the Stream API would be a huge step forward.

To produce an Android app the Android build system converts Java byte code to Dalvik/ART byte code, and currently that conversion process only support converting Java 7 and lower. If you wrote the new code needed to support Java 8 byte code to Dalvik/ART byte code then you can get Java 8 support, but Google has no plans to do that at the moment as it would take quite a bit of effort.

These JVM based languages are able to support the latest and greatest features however because they end up compiling down to Java 7 byte code, which can in turn be converted to Dalvik/ART byte code.

Besides the sibling answers, the situation will only get worse.

Java 9 brings modules.

Java 10 has on its roadmap value types, JNI replacement, GPGPU support, new array model and whatever they might still consider.

Can you expand on this?

If you mean the "getting worse" part, I believe the implication is that Google's lack of control over either Java the language, or the Android device ecosystem upgrades, means the future would likely see increasing fragmentation/divergence in important core language features across Android devices, causing much developer pain.

If one assumes e.g. in comparison Apple will in 2 years have 95% of devices capable of running Swift 3 apps vs. 15% of Android devices capable of Java 8, much less 9/10 ... it could be quite a competitive disadvantage for Android, as well as argument for adopting a forward-looking JVM language dedicated to compiling to 1.6 bytecode if you plan to do Android development.

In what sense? These roadmaps have been presented at multiple Java conferences.

I suspect that ctbattags meant "can you expand on why these will make the situation get worse", rather than "can you expand on what these things are".

But I'm not ctbattags, and I'm not psychic, so I could be wrong...

I see, then themgt's answer covers it.

From a technical point of it just seemed obvious to me.

Reply on news.ycombinator.com