Am I right in thinking that Kotlin already support...
# android
t
Am I right in thinking that Kotlin already supports all new language features introduced in Java 9, 10, 11 and 12, and that supporting those newer Java versions in Android does not add anything for Kotlin Developers ?
a
I think it was announced that there will be no support for Java >8, they went for kotlin first to avoid the desugaring nightmare
j
You are not right, no
ART doesn't even support things like lambdas introduced in Java 8. They are always desugared to classes at compile-time instead of at runtime.
In Java 9 StringConcatFactory was added which changes string concatenation from non-optimal and bloated in bytecode to compact and optimal at runtime. Can't do that despite the performance and binary-size wins.
How about constant dynamic in Java 11 which can move otherwise eager static initializations that occur on class loading to be lazy and automatically thread-safe? Sounds like something that would benefit Android where memory and initialization performance are critical.
I see now you said "language feature" in your original question, but that's a weird comparison because Java hasn't needed 9, 10, 11, 12, or 13 either to support any of its new language features. They're all implemented in the compiler and emit bytecode that has been around forever. The only reason they actually require new versions is that they stopped supporting different source and target versions since it results in a combinatorial explosion of test scenarios with the new release schedule.
The only things which do require new bytecode/VM support are not even exposed at the language level in any capacity (being constant dynamic and nestmates).
r
Is there a reason why they decided not to support the newer version of java? Because I would suspect that would also put a strain on kotlin development because of interoperability . @jw
j
I have no insight into such matters. The lack of tracking the upstream versions will only produce problems later on and it currently is a giant drag on the Java library ecosystem.
p
Would it make sense (for Android) to put more effort on having more tooling and better support for Kotlin/Native once it becomes stable? I know there is support for games and such, but with the likes of
compose
and the fact that okhttp and many other libraries are now xplatform, there may be room to rethink the APIs. Having a VM on a mobile device feels like it’s a bit of drag in terms of performance. The platform team has done an amazing job at making the system be better with every version, however Flutter is a good example of how much more efficient native can be. I could be wrong though 😅
r
Yea true that. Perhaps it's because Oracle was given out Lawsuits like girl-scout cookies lol... Moving away from the VM sounds extremely diffcult. But i do agree,going completely native would be better performance wise
j
Neither Compose nor OkHttp works on Kotlin/Native
r
There are always tradeoffs.. Plus the fact that they would have to go the Apple route and break interoperability. But yea that's just wishful thinking...
j
Yep. Never going to happen.
r
😂😂
Exactly
p
Implemented in Kotlin with a dependency on the Kotlin standard library. We want the option to support coroutines and multiplatform including Kotlin/Native .
https://github.com/square/okhttp/issues/4723 But I could have mentioned Ktor, it’s just an example. And, with compose, what I meant is that it uses Skia underneath (right? I could also be wrong here), so it wouldn’t be a stretch to make it work with K/N.
@rkeazor They are deprecating AsyncTask in Android 11 🙃 One step at a time 😂
r
A micro step lol. They would have to redesign there whole framework
t
So if I understand well, the Android Runtime would really benefit from supporting features that have been introduced in Java 8, 9, 10, 11 and up at the bytecode level since those would really improve performance ?
p
Nope, let’s drop VMs altogether and go straight to K/N 🙃
j
@thibaud yes
t
wrong "Thibaud / Thibault" 😅
j
oof. sorry! autocomplete betrayed me. you'd think it would sort based on people in the thread...