6 ms·

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

by maaaats 11y ago

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?

pjmlp 11y ago
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.
- cdbattags 11y ago
  Can you expand on this?
  - pjmlp 11y ago
    In what sense? These roadmaps have been presented at multiple Java conferences.
    - AnimalMuppet 11y ago
      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...
      - pjmlp 11y ago
        I see, then themgt's answer covers it. From a technical point of it just seemed obvious to me.
  - themgt 11y ago
    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.
chrisseaton 11y ago
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.
- nileshk 11y ago
  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 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.
yiati 11y ago
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.
krschultz 11y ago
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.
- cdbattags 11y ago
  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)?
  - acveilleux 11y ago
    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
- bitmapbrother 11y ago
  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?

by maaaats 11y ago

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?

pjmlp 11y ago

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.

cdbattags 11y ago
Can you expand on this?
- pjmlp 11y ago
  In what sense? These roadmaps have been presented at multiple Java conferences.
  - AnimalMuppet 11y ago
    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...
    - pjmlp 11y ago
      I see, then themgt's answer covers it. From a technical point of it just seemed obvious to me.
- themgt 11y ago
  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.

chrisseaton 11y ago

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.

nileshk 11y ago
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 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.

yiati 11y ago

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.

krschultz 11y ago

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.

cdbattags 11y ago
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)?
- acveilleux 11y ago
  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
bitmapbrother 11y ago
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?