When I generate my application in Java it generate...
# android
r
When I generate my application in Java it generates the java bite code and using it generates the DEX for the android to use. With Kotlin it's the same way? Kotlin -> Java bite Code -> DEX? or go straight from Kotlin -> DEX. If it were Kotlin -> DEX could have direct improvements in android geared towards Kotlin correct?
👍 1
👎 1
g
Yes, exactly the same. .kt -> .class -> .dex
Kotlin team have to concider about generation of dex files directly some time ago (so it would be one more Kotlin backend), at least Andrey Breslav mentioned this a couple times. But this was in time when Android team also experimented with this approach for Java and created Jack compiler for Java But some time ago they decided to deprecate this approach and Jack is dead now, so I think it doesn't make sense anymore for Kotlin too. In theory it sounds really good to skip one intermediate step of compilation, but practically you lose all tooling that works with class files (byte code processors, analyzers etc), also Android Tools team significantly improved dexing (Dex in process, incremental dexing, and now we even have new dexer D8), so for now dexing is not the slowest build step, so it's questionable thing to implement a new compiler (or Kotlin backend) and get insignificant speed up (funny, that Jack was slower than common javac+dexing toolchain even on latest previews before depreciation).
👍 3
r
I understand, I had only thought of it as if in a future of Kotlin wanted to do something really new in the way of working in which Java bite code could not bear (I can not even imagine a sample situation) this way could be made an improvement or something in DEX that would only exist in the conversion kotlin-> DEX
but you did mention important points that I was not taking into consideration