3 ms·

While some of the features in Kotlin are slowly coming to Java, that also means that one has to update Java (while you can use all the new kotlin while still ta

by hv42 7y ago

While some of the features in Kotlin are slowly coming to Java, that also means that one has to update Java (while you can use all the new kotlin while still targeting Java 8). Some features like named parameters or null checking might probably never make it to Java. There is a nice talk about this that compares Kotlin to what will be in Java 19: https://youtu.be/te3OU9fxC8U https://youtu.be/te3OU9fxC8U

vbezhenar 7y ago
If you want null-checking, you can use Nullable annotations. While they're not as good as proper type system, they mostly do the job.
- wtetzner 7y ago
  But you have to remember to use them in all the right places. Yes, they help, but it's not just about how good they are, it's about people actually using them too. If you're working on a team, you need to worry about whether or not everyone else is correctly using the annotations.
pjmlp 7y ago
It also means that Kotlin doesn't get all Java goodies, like virtual threads, value types or GPGPU support.
- thu2111 7y ago
  Virtual threads (Loom) are also not anything affecting bytecode generation, so Kotlin will work with them out of the box. Really, I don't get this claim Kotlin will lack Java features. Most big Java upgrades these days are at the VM level. Kotlin gets those mostly for free, once they choose to upgrade to newer bytecode features (which they are slow at doing admittedly, but that's because they're in the middle of a compiler rewrite).
  - pjmlp 7y ago
    No it won't, because Kotlin also needs to target other platforms, and exposing JVM APIs or new bytecodes needs to have to have that into consideration. It also means that Kotlin on Android cannot just consume any random Java library, only those that are compatible with Android Java flavour of the month.
    - thu2111 7y ago
      Kotlin does expose JVM specific stuff though. Like the entire class library. You have to specifically opt in to the multiplatform subset to avoid that. It's not like they whitelist APIs. The only time they need to do anything to add new Java features is when the bytecode patterns change.
      - pjmlp 7y ago
        Yeah and then funny things happen when one tries to use libraries written in Java with Kotlin ones together. https://dev.to/martinhaeusler/why-i-stopped-using-coroutines-in-kotlin-kg0 https://dev.to/martinhaeusler/why-i-stopped-using-coroutines... https://dev.to/domnikl/kotlin-coroutines-and-javafx-threads-26od https://dev.to/domnikl/kotlin-coroutines-and-javafx-threads-... https://blog.danlew.net/2020/01/28/coroutines-and-java-synchronization-dont-mix/ https://blog.danlew.net/2020/01/28/coroutines-and-java-synch...
yardstick 7y ago
If you are still targeting java8, isn’t that due to organisational constraints about software version management and wouldn’t that normally also imply issues around getting new tools like kotlin into the org too?
- vips7L 7y ago
  Agreed. I highly doubt someone that doesn't want to upgrade their Java version (outside of Android) will be willing to learn and introduce a whole new language.

by hv42 7y ago

vbezhenar 7y ago

If you want null-checking, you can use Nullable annotations. While they're not as good as proper type system, they mostly do the job.

wtetzner 7y ago
But you have to remember to use them in all the right places. Yes, they help, but it's not just about how good they are, it's about people actually using them too. If you're working on a team, you need to worry about whether or not everyone else is correctly using the annotations.

pjmlp 7y ago

It also means that Kotlin doesn't get all Java goodies, like virtual threads, value types or GPGPU support.

thu2111 7y ago
Virtual threads (Loom) are also not anything affecting bytecode generation, so Kotlin will work with them out of the box. Really, I don't get this claim Kotlin will lack Java features. Most big Java upgrades these days are at the VM level. Kotlin gets those mostly for free, once they choose to upgrade to newer bytecode features (which they are slow at doing admittedly, but that's because they're in the middle of a compiler rewrite).
- pjmlp 7y ago
  No it won't, because Kotlin also needs to target other platforms, and exposing JVM APIs or new bytecodes needs to have to have that into consideration. It also means that Kotlin on Android cannot just consume any random Java library, only those that are compatible with Android Java flavour of the month.
  - thu2111 7y ago
    Kotlin does expose JVM specific stuff though. Like the entire class library. You have to specifically opt in to the multiplatform subset to avoid that. It's not like they whitelist APIs. The only time they need to do anything to add new Java features is when the bytecode patterns change.
    - pjmlp 7y ago
      Yeah and then funny things happen when one tries to use libraries written in Java with Kotlin ones together. https://dev.to/martinhaeusler/why-i-stopped-using-coroutines-in-kotlin-kg0 https://dev.to/martinhaeusler/why-i-stopped-using-coroutines... https://dev.to/domnikl/kotlin-coroutines-and-javafx-threads-26od https://dev.to/domnikl/kotlin-coroutines-and-javafx-threads-... https://blog.danlew.net/2020/01/28/coroutines-and-java-synchronization-dont-mix/ https://blog.danlew.net/2020/01/28/coroutines-and-java-synch...

yardstick 7y ago

If you are still targeting java8, isn’t that due to organisational constraints about software version management and wouldn’t that normally also imply issues around getting new tools like kotlin into the org too?

vips7L 7y ago
Agreed. I highly doubt someone that doesn't want to upgrade their Java version (outside of Android) will be willing to learn and introduce a whole new language.